Was ist bitte Flux?

Flux ist eine Architektur die von den Entwicklern von Facebook entworfen wurde. Das Grundkonzept sieht so aus wie die folgende Grafik beschreibt.

Dazu muss man noch wissen das die sogenannten „States“ gibt. Diese werden nie direkt verändert sondern über sogenannte Actions. Im Store werden die States gespeichert. Um mehr über diese Architektur zu erfahren am besten unter Flux Dokumentation einlesen. Zurück zu Vue.js und Vuex.

Warum brauche ich Vuex?

Wenn man ein Einsteiger für dieses Architektur Modell ist und noch nicht genau weiß warum das überhaupt benötigt ist die Lern bzw. Verständniskurve ziemlich hoch. Aber ich gebe mal ein Beispiel: Man baut eine kleine Messenger App und möchte in mehreren Komponenten anzeigen wenn es eine neue Nachricht gibt. Dazu ist diese Architektur Form ideal, die Idee wäre wenn eine neue Nachricht eintrifft wird eine Action aufgerufen und diese verändert den State. In den einzelnen Komponenten muss dann nur auf den Store zugegriffen werden.

Vuex hat diese Teile der Architektur so aufgeteilt:

• Store
• Actions
• Mutations
• Getters

So wird der Store definiert

import Vue from 'vue'
import Vuex from 'vuex'
Vue.use(Vuex)
 const store = new Vuex.Store({
 state: {
 },
 actions: {
 },
 mutations: {
 },
 getters: {
 },
 modules: {
export default store
}
})

Der State ist die Datenstruktur der benötigten Daten in der App. Kann ein Default oder Initial Wert sein.

state: {
  projects: [],
  userProfile: {}
}

Actions werden in den Komponetnen durch den sogenannten “dispatch call” aufgerufen.

actions: {
    LOAD_PROJECT_LIST: function ({ commit }) {
      axios.get('/secured/projects').then((response) => {
        commit('SET_PROJECT_LIST', { list: response.data })
      }, (err) => {
        console.log(err)
      })
    }
  }

Mutations sind der einzige Weg um den Store zu aktualisieren.

mutations: {
    SET_PROJECT_LIST: (state, { list }) => {
      state.projects = list
    }
  }

Getters sind die Methoden um den derzeitgen Stand vom State zu bekommen.

mutations: {
    SET_PROJECT_LIST: (state, { list }) => {
      state.projects = list
    }
  }

The post Die Idee von Vuex appeared first on Mobile USTP MKL.

insecure

Dieses Package gibt die Möglichkeit die Collection(Datenbank) direkt vom Client zu bearbeiten. Hierbei ein nützlicher Link: https://www.meteor.com/tutorials/blaze/security-with-methods

autopublish

Dieses Paket schickt ununterbrochen alle Collection vom Server zum Client, deswegen kann der Client auf alle Daten in jedem Template zugreifen. Hierbei ein nützlicher Link: https://www.meteor.com/tutorials/blaze/publish-and-subscribe

Um einen Überblick zu schaffen hier eine kleine Grafik wie der Lebenszyklus für publish und subscribe aussieht:

Damit der Client auf „subscriben“ kann muss die publish Methode am Server deklariert sein. Hier ein Code-Beispiel(in CoffeeScript), es werden alle Daten von der Collection Polls geholt.

Meteor.publish 'allPolls',

return Polls.find()

Dieser Code ist natürlich im Serverseitig, jetzt wird die Subscribe Methode auf der Clientseite gezeigt.

Template.polls_index.onCreated

@autorun

@subscribe('allPolls')

Wenn das Template erstellt wird, wird die autorun Methode ausgeführt und diese holt sich alle „Polls“ dann kann der Entwickler mit den „Polls“ weiterarbeiten (z.B.: die Polls ausgeben).

So werden publish und subscribe Prozesse ordnungsgemäß bei Meteor behandelt. Wenn jeder Anfrage von der Clientseite mit subscribe gelöst, wurde kann das autopublish Paket gelöscht werden und der Entwickler kann testen ob seine Abläufe funktionieren.

Zur nächsten Thema, um Daten in der Collection speichern zu können liefert Meteor sogenannte call Methoden mit. Diese Methoden organisieren auf der Serverseite die Datenverarbeitung und kommunizieren mit der Collection. Achtung zusätzlich in diesem Beispiel wird das Package Astronomy(http://astronomy.jagi.io/what-is-astronomy) verwendet.

Der Clientseitige Code, durch die call Methode wird der Zugriff auf den Server angefordert:

poll = new Poll {

title: @title

description: @description

duration: @duration

charttype: @charttype

ownerId: Meteor.userId()

}

$opt = $('input[class^="option"]')

$.each $opt, (index, v)

poll.push 'options_poll', optiontitle: $opt[index].value

Meteor.call('addPoll', poll)

Und auf der serverseitigen Seite, wird der Code folgend verarbeitet:

Meteor.methods

'addPoll': (poll)

if poll.validate()

poll.save()

FlowRouter.go('polls_index')

Return

Jetzt ist es möglich das Package insecure zu löschen und die Datenspeicherung funktioniert. Ich hoffe ich konnte einen Einblick Meteor und seinen Security Bereich geben.

The post Meteor und die Packages Autopublish und Insecure appeared first on Mobile USTP MKL.

Änderung der Maßeinheit

In den vorigen Versionen wurde Pixel als Maßeinheit verwendet. Jetzt wird die relative Maßeinheit rem(root em) verwendet.

IE8 wird nicht mehr unterstützt

Weil der Internet Explorer 8 die Maßeinheit rem nicht unterstützt wird diese Version nicht mehr unterstützt. Da der Browsermarktanteil beim IE8 unter 2% liegt, wird es nicht so ein großer Verlust sein.

The Sass Way

Bootstrap hat den Pre-Prozessor gewechselt und zwar von Less auf Sass. Zwar war in Bootstrap 3 eine Sass Version vorhanden. Aber jetzt wird es nur eine Sass Version geben, Grund dafür ist weil sich Sass immer mehr gegen Less durchsetzt.

Verbesserte Media Queries

Da es in Vorgänger Versionen immer wieder Problem mit verschiedenen Geräten(z.B.: iPad) gab. Viele Web Entwickler schrieben ihre eigenen Queries wenn das Framework verwendet Deswegen wurden Media Queries in „Mobile First“ und „Desktop First“ aufgeteilt.

// Small devices (landscape phones, 34em and up)
@media (min-width: 34em) { ... }

// Medium devices (tablets, 48em and up)
@media (min-width: 48em) { ... }

// Large devices (desktops, 62em and up)
@media (min-width: 62em) { ... }

// Extra large devices (large desktops, 75em and up)
@media (min-width: 75em) { ... }
  
// Extra large devices (large desktops)
// No media query since the extra-large breakpoint has no upper bound on its width

// Large devices (desktops, less than 75em)
@media (max-width: 74.9em) { ... }

// Medium devices (tablets, less than 62em)
@media (max-width: 61.9em) { ... }

// Small devices (landscape phones, less than 48em)
@media (max-width: 47.9em) { ... }

// Extra small devices (portrait phones, less than 34em)
@media (max-width: 33.9em) { ... }

Cards Layout

Das neue Cards Layout ersetzt die bekannten Komponenten Panels and Wells. Cards sind definierte als flexible Content Container, das erlaubt Optionen wie Header und Footer. Es ist eine sehr individuelle Darstellung von Content möglich. Um alle Variationen dieses Layouts zu sehen ist, hier der Link (http://v4-alpha.getbootstrap.com/components/card/). Noch ein nettes Feature ist das Cards-Column Layout, das eine Collage ermöglicht.

Fazit

Bootstrap 4 Alpha macht gespannt auf die Release Version, aber jezt kann man sagen das sie coole neue Features mitliefert. Die Alpha Version hat noch viele neue Styling und Helperklassen dabei. Für mehr Informationen kommen jetzt noch nützliche Links.

https://scotch.io/bar-talk/whats-new-in-bootstrap-4

http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/

The post Bootstrap 4 appeared first on Mobile USTP MKL.

Als Initialprojekt für das Fach Mobile Anwendungen ist es mir mehr um die Methode als um das Projekt gegangen und deswegen haben hab ich die Applikation mit Meteor umgesetzt. Trotzdem Die Applikation war eine kleine Geo-Location Applikation, die den nähersten Standort anzeigt und Informationen über diesen Standort anzeigt. In diesem Fall soll er Informationen über Standorte in Wien anzeigen(Schwedenplatz, Naschmarkt,…).

Wie schon vorher erwähnt wurde ist Meteor als Plattform verwendet worden. Im Frontendbereich hab ich das Framework Bootstrap verwendet.

Probleme MongoDB und GeoJSON

Für die Berechnung für den nähersten Standort habe ich die von MongoDB und GeoJSON verwendete Filtermethode $near verwendet. Dabei ist eine Konfiguration auf der Datenbank notwendig damit GeoJSON und der Filter verwendet werden können. Für zukünftige Leser die Probleme mit MongoDB und GeoJSON haben, sollten schauen das dieser Index direkt auf der Datenbank erstellt ist.

db.collection.createIndex( { <location field> : "2dsphere" } )

Wichtig ist auch bei der Verwendung von GeoJSON die richtige Struktur zu verwenden, sonst wird es wahrscheinlich auch Probleme geben. Hier ist eine Beispielstruktur für die eine GeoJSON Format:

{

  "type": "Feature",

  "geometry": {

    "type": "Point",

    "coordinates": [125.6, 10.1]

  },

  "properties": {

    "name": "Dinagat Islands"

  }

}

Der $near Filter liefert dann ein sortiertes nach der Nähe des Standortes Array zurück. Dann können die Daten mit den Handlebar Funktionen von Meteor ausgegeben werden.

Fazit

Meteor ist sehr spannend, aber in Kombination mit dem GeoJSON war es etwas trickreich.

Ich möchte dieses Projekt unbedingt erweitern und weiter daran arbeiten, wer Interesse hat bestplacesinvienna.meteor.com

STAY TUNED!

The post Best Places in Vienna appeared first on Mobile USTP MKL.