Javascript: “Pull to refresh”

Pull-to-refresh in (mobilen!) Webseiten nachzubauen, ist jetzt keine Raketenwissenschaft, aber doch so viel Aufwand, dass sich ggf. eine Library lohnt. Viele (? einige? apeatling, ember-gestures, …) bauen aber auf hammer auf, und das hat einen Bug (Beispiel, es gibt weitere Tickets) im Zusammenspiel von Panning (also dem “Pull” in “Pull-to-refresh”) und Scrolling. Zusammengefasst: Es geht nur eines von beiden. Mit ein wenig Drumherumgehacke bekommt man das etwas näher zusammengeführt, aber entweder kommt PanEnd dann gar nicht (was das “refresh” schwierig macht), oder bspw. die PanMove-Events kommen nicht zuverlässig (wodurch man den “pull” nicht 1:1 an den Finger des Nutzers hängen kann).

Ein npm-Modul, das nicht auf hammer aufbaut, wäre pulltorefreshjs (getestet mit 0.1.11 und 0.1.13):

PullToRefresh.init({
  mainElement: '.myCssSelector',
  onRefresh: () => {
    console.log('hello moto')
  },
});

PullToRefresh.init({

mainElement: '.myCssSelector',

onRefresh: () => {

console.log('hello moto')

});

In Ember sieht das als Komponente so aus:

import Component from '@ember/component';
import PullToRefresh from 'npm:pulltorefreshjs';
import {get, set} from '@ember/object';
import {getOwner} from '@ember/application';
import {inject as service} from '@ember/service';

export default Component.extend({
  classNames: ['pull-to-refresh'],

  router: service(),
  currentRouteInstance: undefined,

  didInsertElement() {
    this._super(...arguments);

    const owner = getOwner(this);
    const currentPath = owner.lookup('controller:application').currentPath;
    set(this, 'currentRouteInstance', owner.lookup(`route:${currentPath}`));

    // TODO use unique identifier for mainElement, store result of init()
    PullToRefresh.init({
      mainElement: '.pull-to-refresh',
      onRefresh: () => {
        get(this, 'currentRouteInstance').refresh();
      },
    });
  },

  willDestroyElement() {
    this._super(...arguments);

    // TODO destroy current ptr only; id is returned by init()
    PullToRefresh.destroyAll();
  },
});

import Component from '@ember/component';

import PullToRefresh from 'npm:pulltorefreshjs';

import {get, set} from '@ember/object';

import {getOwner} from '@ember/application';

import {inject as service} from '@ember/service';

export default Component.extend({

classNames: ['pull-to-refresh'],

router: service(),

currentRouteInstance: undefined,

didInsertElement() {

this._super(...arguments);

const owner = getOwner(this);

const currentPath = owner.lookup('controller:application').currentPath;

set(this, 'currentRouteInstance', owner.lookup(`route:${currentPath}`));

// TODO use unique identifier for mainElement, store result of init()

PullToRefresh.init({

mainElement: '.pull-to-refresh',

onRefresh: () => {

get(this, 'currentRouteInstance').refresh();

});

willDestroyElement() {

this._super(...arguments);

// TODO destroy current ptr only; id is returned by init()

PullToRefresh.destroyAll();

});

Auf dem Handy sollte das so schon funktionieren. Auf dem Desktop hatte ich das Phänomen, dass Hochcrollen immer erst beim zweiten mal funktioniert hat (und auch dann nur, wenn zwischen Versuch 1 und 2 nicht zu viel Zeit lag). Weil: Die Lib immer beim Hochscrollen den Loader anzeigt, wenn man die Funktion shouldPullToRefresh nicht vom default !window.scrollY ummapt, bspw. auf

shouldPullToRefresh: () => {
  let scrollTop = this.$().parent()[0].scrollTop;
  return scrollTop === 0;
},

shouldPullToRefresh: () => {

let scrollTop = this.$().parent()[0].scrollTop;

return scrollTop === 0;

Hochscrollen geht sonst nur, so lange der Loader angezeigt wird 🙃

Generische npm Module in Ember

Wer, wie ich, die ~~verfilzte~~ komplexe Javascript-Umgebung etwas… “unübersichtlich” findet, und sich fragt, wie zur Hölle man ein nicht-Ember-spezifisches npm-Modul in Ember importiert, dem kann geholfen werden:

Erst Browserify:

npm install ember-browserify --save-dev

1	npm install ember-browserify --save-dev

dann, voilà:

import PullToRefresh from 'npm:pulltorefreshjs';

1	import PullToRefresh from 'npm:pulltorefreshjs';

JS: navigator.language im Chrome

Chrome ist der neue Internet Explorer:

// IE:
let language = navigator.userLanguage;

// "everyone else" (as found in most tutorials):
let language = navigator.language;

// actually working:
let language = navigator.languages[0] || navigator.language || navigator.userLanguage;

// IE:

let language = navigator.userLanguage;

// "everyone else" (as found in most tutorials):

let language = navigator.language;

// actually working:

let language = navigator.languages[0] || navigator.language || navigator.userLanguage;

Stellt sich raus: navigator.language ist im Chrome die Sprache des UI, nicht “Accept-Language” m(

navigator.languages funktioniert dafür auch im FF und liefert alle akzeptierten Sprachen.

EaselJS: Lift-off und OOP [UPDATE]

Also zuerst mal sollte diese EaselJS-Geschichte nun nicht mehr nur auf der Startseite funktionieren – mea culpa!

Was EaselJS für mich so richtig interessant macht, ist die Tatsache, dass jedes Objekt auf dem Canvas eigenständig bleibt – so wie ich das Canvas-Element verstehe (als eine Art Bitmap/BitmapData), ist das nicht immer so? Dadurch kann man diesem kleinen Ball aus meiner Demo zum Beispiel einen Click-Handler geben, wie soeben geschehen.

Dabei ist mir Folgendes aufgefallen: Wenn ich tatsächlich nach und nach mehrere (ausgefeiltere) Demos bauen will, dann würde es der Übersichtlichkeit dienen, wenn ich diese voneinander separieren könnte. Am Liebsten in ihrem jeweils eigenen Objekt, von denen ich dann jeweils eines instanziiere. Nur: Wie funktioniert objektorientiertes Programmieren in JS? Meine JS-Kenntnisse sind etwas eingerostet, aber hier gibt es eine nette Basic- (!) Einführung.

Das Ergebnis kann man sich im Quellcode ansehen: Alle Variablen, die nur zur (bisher einzigen) Demo gehören, sind in “Klasse” “A” ausgelagert… I like! Nun könnte es eigentlich/vielleicht losgehen.

UPDATE:

Hm, andererseits wäre es auch interessant, “richtiges” OOP zu sehen, z.B. das Beerben von EaselJS’ Klassen. Angenommen, ich möchte ein TicTacToe-Spiel bauen, dann hätte ich Kreuze und Kreise, die beide (mir fällt grad kein besserer Begriff ein) Spielsteine (engl. “Tile”)sind, der wieder meinetwegen ein Shape ist. Wenn ich diese etwas ausgefeiltere Einführung als Ausgangspunkt nehme, sieht das so aus:

Tile.prototype = new Shape();
Tile.prototype.constructor = Tile;
Tile.prototype.g;
function Tile()
{
	this.g = new Graphics();
	Shape.prototype.initialize.call( this, this.g );
}

Circle.prototype = new Tile();
Circle.prototype.constructor = Circle;
function Circle()
{
	this.g.setStrokeStyle( 1 );
	this.g.beginStroke( Graphics.getRGB( 0, 0, 0 ) );
	this.g.drawCircle( 0, 0, 10 );
}

Cross.prototype = new Tile();
Cross.prototype.constructor = Cross;
function Cross()
{
	this.g.setStrokeStyle( 1 );
	this.g.beginStroke( Graphics.getRGB( 0, 0, 0 ) );
	this.g.moveTo( 0, 0 );
	this.g.lineTo( 18, 18 );
	this.g.moveTo( 0, 18 );
	this.g.lineTo( 18, 0 );
}

Tile.prototype = new Shape();

Tile.prototype.constructor = Tile;

Tile.prototype.g;

function Tile()

{

this.g = new Graphics();

Shape.prototype.initialize.call( this, this.g );

}

Circle.prototype = new Tile();

Circle.prototype.constructor = Circle;

function Circle()

{

this.g.setStrokeStyle( 1 );

this.g.beginStroke( Graphics.getRGB( 0, 0, 0 ) );

this.g.drawCircle( 0, 0, 10 );

}

Cross.prototype = new Tile();

Cross.prototype.constructor = Cross;

function Cross()

{

this.g.setStrokeStyle( 1 );

this.g.beginStroke( Graphics.getRGB( 0, 0, 0 ) );

this.g.moveTo( 0, 0 );

this.g.lineTo( 18, 18 );

this.g.moveTo( 0, 18 );

this.g.lineTo( 18, 0 );

}

Potential für Verbesserung sehe ich hier:

Kreis und Kreuz nur je einmal zeichnen und wiederverwenden (siehe Doku zu Shape), statt jedes mal im Konstruktor.
DisplayObject.cache() verwenden.

Meinungen?

EaselJS: Kickoff

So ein Blog ist ein tolles Spielzeug. Eigentlich wollte ich nur meine Tweets anzeigen. Dafür brauchte ich ein neues Theme (das alte hatte keine Sidebar^^). Das neue ist schick, aber hat da oben diesen grauen Header, für den ich eigentlich keine Verwendung habe… lange Rede, kurzer Sinn: Ich benutze es jetzt als Canvas für EaselJS, mit dem ich gerade rumspiele.

Mittelfristig möchte ich da random das anzeigen, was bei meinen Spielereien so abfällt. Bis auf weiteres muss es aber eine Abwandlung einer Demo von Mike Chambers tun.

[Firefox] ExternalInterface.call() von außerhalb “der Bühne”

firefox

Man liest von ExternalInterface-Problemen, die darauf basieren, dass von Javascript aus AS-Funktionen aufgerufen werden, bevor das SWF geladen ist – etwa bei onLoad. Als Lösung gilt: “Rufe aus dem SWF heraus eine JS-Funktion auf. Dann (und erst dann) weiß JS, dass das SWF bereit ist.”

So weit, so gut.

Was man dazu wissen muss, und was man deutlich weniger schnell findet im Netz: Ein SWF, das außerhalb des sichtbaren Bereiches liegt (etwa bei “position: absolute; top: -10px; left: -10px;”), ruft im Firefox 3/Windows keine ExternalInterface-Funktion auf. Gar keine, nie. Obwohl ExternalInterface.available true ist, und obwohl das SWF eigentlich angezeigt wird.

HTH.

crusy.net

♪ Commit ins Abenteuerland ♫

Tag Archives for JS