22

BackboneとZeptoで開発されたシングルページモバイルアプリケーションがあります。

ブラウザの戻る/進むボタンで正しく機能します。

ユーザーがページに移動すると、古いコンテンツが左にスライドして（ビューポートから出て） 、新しいコンテンツが右からスライドインします。ユーザーが「進む」ブラウザボタンを押した場合にも同じことが起こりたいです。これはすべて機能します。

この動作を反転させるクラスをbody要素に追加したnavigate-backので、ユーザーがブラウザーの戻るボタンで戻ると、コンテンツが左からスライドして戻り、他のコンテンツが右にスライドするのがわかります。基本的には、前進するのとは正反対です。

別の動作を呼び出すことができるように、ユーザーが逆方向にナビゲートしているかどうかを検出する必要があります。私は自分の履歴スタックを実装しようとしましたが、多くの問題に遭遇しました。それは、視覚的な手がかりを台無しにする後方ナビゲーションとして前方をマークすることがあります。それは今やハックの寄せ集めに陥っており、おそらく私がそれを投稿した場合にのみ私を当惑させるでしょう。

ユーザーが単一ページのBackboneモバイルアプリケーションのコンテキストで前後に移動しているかどうかを検出できるように、独自の履歴スタックを実装するための最良の方法は何ですか？

4

5 に答える 5

22

backbone.js 1についてはわかりませんが、html5 でこの動作を正確に実装する必要があるモバイル アプリケーションの開発を支援したので、良いアドバイスを提供できるはずです。

まず第一に、history.pushState関数が存在することを知っておくとよいでしょう。ただし、大きな問題は、android 2.3 まではサポートされていますが、android 3 から android 4.0.3 まではサポートされていないことです。kiranvj が正しく指摘しているように、履歴機能の欠如に対するポリフィル ソリューションを提供する人気のhistory.jsライブラリを使用することで、これを解決できます。

さて、実際の問題に取り掛かると、履歴方向のアニメーションを実装する方法は、ページの論理位置を特定するpushState関数 ( ) にデータを追加することでした。history.pushState(data,title,url)私のアプリケーションでは、水平バーに限定されていませんでしたが、あなたの場合、新しくロードされたページが現在のページよりも 1 つ高い位置になる位置を追跡します。例えば

History.pushState({position:History.getState().data.position+1},"Your title","Your URL");

次に、window.onstatechangeまたはwindow.onanchorchangeイベントがトリガーされると、位置が現在のページよりも高いか低いかを観察し (たとえば、上記で使用したhistory.js History.getState()関数を使用して)、これに応じて、どちらの方向に移動するかを決定します (下は下の画像で示されているように、左が左で、右が上です。

歴史上の出来事のイラスト

{position:1}また、通常、最初のページには状態情報がありませんが、最初のページには既にあると想定していることにも注意してください。これを実現する方法は、 which を使用しhistory.replaceStateて、現在の空の状態をより有益な状態に置き換えることです。または、前述のイベントのいずれかで空の状態を確認することもできます。空の場合は、一番左のイベント ( {position:1}) であると想定します。

ご不明な点がございましたら、お気軽にお問い合わせください。

この回答はhistory.jsを使用していることを前提としており、独自のソリューションを構築する場合は、わずかに異なるイベント ( などonpopstate) をリッスンし、わずかに異なる構造 (historyではなく) を使用する必要があることに注意してください。History

また、独自のキュー配列を使用してこれを構築することもできます。これにより、より多くの制御が可能になりますが、ブラウザの戻るボタンと組み合わせて機能することはありません。これはブラウザー サイトでは大きな問題ですが、 cordova (別名phonegap ) Web アプリケーションを構築している場合は、はるかに簡単です。

1 それについて読んだだけで、独自の履歴処理を行っているように見えます。これにより、上記の手法を統合するのがより複雑になる可能性があります。

于 2012-06-05T08:25:42.850 に答える
1

真のシングルページアプリで作業している場合は、js変数に履歴URLを保持する配列を設定してみませんか（のようなものhistory.pushStateとそのサポートに依存するのではなく）？

新しいページに移動するときはいつでも、そのURLを配列にプッシュできます。「戻る」ボタンを押すたびに、必要なURLを必要なだけさかのぼって取得できます。これは、ユーザーが数ステップ戻って新しいリンクに移動したときにURLを正しく破棄する限り、完全に機能します。

ページ履歴に使用するためにこれを実装しようとしたことはありませんが、これはページ内の元に戻るロジックには完全に機能しました。

アップデート：

さらに調査した後、上記のアプローチは、JSを介して利用可能な履歴処理の外部で発生するアクションであるため、ページのリロードには機能しません。バック/フォワードトランジションの追跡には引き続き機能しますが、アプリの外部のURLに移動したり、ページを更新したりすると、そのような履歴は失われます。David Mulderの答えは、ページスコープの外で存続するブラウザレベルの履歴に依存することにより、この制限を欠いているようです。

于 2012-06-06T23:28:39.610 に答える
1

モバイルで Zepto を単一ページの複数ビューで使用しているときに、同じ問題が発生しました。

最初は、html5 の statechange と onhashchange を使用しました。それはすべて、1つまたは他のモバイルデバイスにいくつかの問題があります. 最後に、ここから Zepto 履歴プラグインを使用しましたhttps://github.com/browserstate/history.js

それはほとんどの問題をいくらか解決しました。試してみてください。便利です。可能な限り html4 および html5 の機能を処理します。

于 2012-06-03T05:11:58.493 に答える
0

このことを単一ページのモバイルアプリケーションで使用すると、履歴が可能になり、ユーザーを元に戻すことができます。

function onBackKeyDown() {
    history.go(-1);
    navigator.app.backHistory();
}
于 2015-11-27T13:36:35.347 に答える
-2

Sammy.jsのv.6.xブランチ（ハッシュの変更のみに依存するブランチ）は、履歴を追跡するための完璧で、最も単純で、最もブラウザー互換性のあるアプローチです。そこでは、サミーがハッシュチェンジを監視しているだけなので、履歴はまったく追跡されません。

「＃/ slide / 123」に依存することで、ハードページのリロードをサポートし、作業を簡素化できます

各ページビューの最後の部分（スライド番号）をはがし、グローバルにプッシュします。新しいルートで、番号がグローバルに保存されている数より多いか少ないかを確認し、正しい（左または右）アニメーションを実行します。グローバルが定義されていない場合、アニメーションはありません。

于 2012-06-09T20:00:52.817 に答える