I'm using Cordova / Phonegap for a mobile application, along with backbone.js for MV* support. This app is likely to be used where there is no internet connectivity for large periods of time, so I'd like to bundle some help files along with the app -- so that they can be used offline.
Right now I just have the beginnings of a single Backbone View to display help topics:
var HelpView = require('app/views/HelpView'),
helpView = new HelpView();
return Backbone.Router.extend({
routes: {
"": "home", // (top level)
"help": "help", // #help
//etc.
},
help: function () {
helpView.delegateEvents();
slider.slidePage(helpView.$el);
},
// etc.
But this kind of feels like I'm reinventing the wheel. Are there any sorts of best practices / frameworks for help support out there?
I realized that I hadn't followed up here with what we ended up doing. Which is, well, not really a separate help system.
We ended up using a help walkthrough system instead. A bit simpler, but mobile apps should be designed to be intuitive enough to work through with just a basic orientation. There are several UX patterns out there for implementing walkthroughs (Here are some) -- and several javascript frameworks out there as well:
Bootstro.js: http://clu3.github.io/bootstro.js/
Bootstrap Tour: http://github.com/Gild/bootstrap-tour
Chardin.js: http://heelhook.github.io/chardin.js/
Hopscotch.js: https://linkedin.github.io/hopscotch/
Intro.js: http://usablica.github.io/intro.js/
Joyride: http://zurb.com/playground/jquery-joyride-feature-tour-plugin
I had originally started with Joyride, but there were some CSS class collisions that were causing headaches. We ended up with hopscotch.js, which is maintained by LinkedIn and also offers support for localizations of the walkthrough text (nice!).
Related
Hi I need your help trying to figure it out something.
First a little background, I was used to code in Django, it was fast to code and good, but times change and Node is taking over most of new apps, then I move to Express a couple of years ago, however I still miss a lot of the Django functionality, then I start coding a little library to help me with common tasks, then start growing until the current point where you have a core library and plug-able “apps” to do recurrent tasks, like notifications, auth and more, or at least that’s the plan.
Right now an app works something like this:
./controllers (All renders)
./endpoints (Restfull API endpoints)
./models (Static and DB models)
./public (Public files)
./style (Scss styles with bootstrap injected)
./views (Default templates, distributed with the app as example, loaded by default)
…/…/views (Custom views to rewrite the default ones from the app)
On start, JSloth compile everything for you and run the server (hot reload included):
Now, that works fine using an static multipage environment, but I will love to use Angular for that, changes will be needed but I want you guys to lead me in the right direction.
So far I have 2 ideas:
1- Split Routes/Html apps and Restful/Endpoints, then basically use an standard set up on that kind of apps with webpack and AngularSSR.
The big downside is, you can’t give an out the box frontend implementation for apps.
2- Figure it out a way to provide an Angular app for each JSloth app, in this way if you install/copy the auth app you will be provided of user lists, interfaces to update your profile, etc.
I’m thinking that may be a problem talking about performance because in this way you will have a lot of Angular apps, am I wrong?
I need a easy way to allow the final user to share footers and headers at least, maybe even styles or scss variables for colors, in that way it will not look like a huge change.
Do you have any other option? Any better idea?
Thank you so much for the help, this is the repository: https://github.com/chrissmejia/JSloth
Edit 1: Forgot to add the models folder
I am struggling with some details about finding a solution to make an Angular / C# app available offline.
My idea would be to use upup.js the get the business logic for the SPA in Angular available offline. upup.js uses service workers to do so. I would store the data required for the offline app using angular-localForage which uses IndexedDB and falls back to WebSQL and localStorage in case.
The problem is, that I have to make files and images available offline too without requiring the user to visit the page they are being used on and I am worried about the maximum quotas. I could store them using either upup.js and adding those files as assets, or store them with angular-localForage as blobs. IndexedDB is supposed to be unlimited by now if I am informed correctly? I couldn't find any maximum quota for a service worker though, as the upup.js solution would use. The AppCache is deprecated, so I wouldn't use that... Or maybe I understood something completely wrong, or there is even another, better solution? Anyhow, the question is:
TL;DR: What is the better way to store files for an AngularJS offline application: angular-localForage (IndexedDB etc.) or a Service Worker (upup.js) and what are the maximum quotas for each solution? Or is there an even better solution?
In my opinion Service Worker (SW) is better than tradition local storage. Plus SW can also use indexedDB.
For the implementation, it is very depending. How your app structure, what technologies of front-end being with with your angular app, what is your main goals of using SW...?
1. Traditional JS loading, you are likely merge all the JS file in one... like app.js contains everything.
And you also don't care about Push Notification neither any other cool features that SW offering.
=> For this case it seem like upup.js suite you the best.
NOTE : beware that upup.js attempt to registering SW on it own, so it likely blocking or complexified your work on expanding feature of SW.
2. Advanced AMD user, where almost all of your JS chopped to small pieces... like fooCtrl.js, barCtrl.js, etc...
For sure you don't want to configure like 100+ files of JS, and further more you will got a lot of html template to load.
=> In this case I will suggest you to use sw-toolbox . A very powerful and light weight tool made by Google. At initial if you are not familiar with SW concept yet, you will have a bit of trouble setting it up for your site (but it won't be longer than a day of you are an advanced JS developer)
After all has configured, all become so very simple. For example this is how I cache all of static content in my site.
self.toolbox.router.get(/(.js|.css|.png|.jpg|.json|.html)/, self.toolbox.fastest);
3. You don't care about what kind of technology at front-end side. You just interest with SW.
=> Simply go for sw-toolbox it's a real time-saver for basic configuration. And if you want to expand the usage of SW, you can just expand it by your own will.
We have an app/website using Angular 1.5. It'll take time to convert everything to Angular 2 and it isn't a priority as what we have currently work.
I was thinking it could be interesting for new components/directive/services to write them in Angular 2, to avoid having to eventually convert them later on, as well as to start learning the new syntax.
But is it really a good idea to ship something containing Angular 1.5 and 2 with ngUpgrade? The memory footprint should end up being bigger, but are there other drawbacks?
The following article http://blog.thoughtram.io/angular/2015/10/24/upgrading-apps-to-angular-2-using-ngupgrade.html by Pascal Precht mentions: Keep in mind that the goal of this [upgrade] phase is to stay in it as little as possible, since running both frameworks on the same website is surely not ideal. but that doesn't tell us much.
Does anyone have feedbacks with a "real" (ie not tiny or proof of concept) partial update using ngUpgrade?
We have a large commercial product (banking web-application) and we use a hybrid application on production.
We migrate services and components from AngularJS 1.5 to Angular 6, and it will take at least a half year.
A few tips:
To avoid all issues with $digest and performance I recommend using DowngradeModule - it bootstraps AngularJS outside of the Angular zone and keeps the two change detection systems separate.
The first hybrid app used UpgradeModule and we had a lot of problems, - this approach is not for large applications.
Use similar code before bootstrapModule(AppModule)
import { enableProdMode } from '#angular/core';
if (IS_PRODUCTION) {
enableProdMode();
}
If you have any questions - you are welcome.
I am researching best practices for developing 'classic' style mobile sites, i.e., mobile sites that are delivered and experienced as mobile HTML pages vs. small JavaScript applications (jQuery Mobile, Sencha, etc.).
There are two prevailing approaches:
Deliver the same page structure (HTML) to all mobile devices, then use CSS media queries or JavaScript to improve the experience for more capable devices.
Deliver an entirely different page structure (and possibly content) to devices with enhanced capabilities.
I'm specifically interested in best practices for the second approach. Two good examples are:
MIT's mobile site: different for Blackberries and feature(less) phones than for iOS & Android devices, but available at the same URLs -- http://m.mit.edu/
CNN's mobile site: ditto -- http://m.cnn.com/
I'd like to hear from people here at SO have actually worked on something like this, and can explain what the best practices are for delivering this type of device-dependent structure/content/experience.
I don't need a primer on mobile user-agent detection, or WURFL, or any of the concepts covered in other (great) SO threads like this one. I've used jQuery Mobile and Sencha Touch and I'm familiar with most approaches for delivering the final mobile experience, so no pointers required there either thanks.
What I really would like to understand is: how these specific types of experiences are delivered in terms of server-side detection and delivery based on user-agent groups -- where there's one stripped down page structure (different HTML) delivered to one group of devices, and another richer type of HTML document delivered to newer devices, but both at the same sub-domain / URLs.
Hope that all makes sense. Many thanks in advance.
At NPR, we use a server side 'application' to serve up the correct html/css/etc depending on if the user is on a high-end device or a lower-tier phone.
So, when a mobile device pings an npr.org page, our servers use a user-agent detection method to point them to the corresponding m.npr.org. Once directed to the m.npr.org URL, the web app - which is written in groovy, but I think could potentially be a number of things - sends back either the touch version of the site or the more simple, stripped down content. The choice of the web app is made based at least somewhat on the WURFL data.
I don't have enough rep points to post a comparison with screenshots, so I'll have to point you to the sites themselves.
You can see this in your desktop browser by typing in m.npr.org to see the stripped down site. And you can override the default device detection by adding the parameter ?devicegate.client=iPhone_3_0 to see the touch version you would see if you just went to npr.org on your smartphone. If you view the source, you can see how different html & css is being served at the same subdomain.
Hope it helps seeing something like this in the wild. Does that make sense?
A common way to detect which format a mobile device needs is the accept header:
application/xhtml+xml > xhtml
text/vnd.wap.wml > Old wml wap pages
.
.
.
On newer devices which can handle all the desktop html formats, you can use the user agent.
Then you have to ask yourself what you want to do:
Switch to another Stylesheet (only works with newer devices).
Switch to another view logic, like building wml page templates.
Switch to a complete other page.
I think the second approach is the best one. Many web frameworks make it easy to switch to another view logic without rewriting the rest (the mvc pattern in its glory).
I have two examples for you.
Read up on how facebook achieves this using XHP to give abstract different output for different markups: One Mobile Site to Serve Thousands of Phones
There will be a lot of good stuff in their actual implementation which I wish was available.
I use a framework called HawHaw, which let's you write your app once (in PHP Objects or XML files) and it outputs the correct markup to the device based on a few checks (accept header, agent string etc).
I'm looking for the following info:
Full Phonegap reference (couldn't find it on their site)
What's the easiest way to implement a database within Phonegap?
Update 2015
The answer below is very out date (and since it recently got an upvote I thought I better readdress it), the Cordova Docs is now the definitive place for documentation, though currently the plugin docs link to the NPM pages which are kind of in transition and a mess. As for the best way to store date, sqllite database that was built into webkit is either gone or deprecated. Lawnchair has been the defacto standard for the past 5 years, as you could swap storage engines in and out, LocalStorage is the simplest way to store data, but beware you around a 5 megs maximum (and I have run into corruption issues with it). I would recommend looking at something like sqllite plugin if you need more than 5 megs (it also has a LawnChair adaptor), or PouchDB and its Cordova Adaptor if you need syncronization to the cloud.
I've left the original answer for posterity...
Original Answer - Circa 2010
The Wiki is the closest thing that phonegap has to a full reference, though it isn't the easiest thing to find on their site. The Javascript API page is probably the most complete reference on external functions available, although it may be a little out of date. The best thing you can do, if something isn't functioning as documented, is go to the Javascript API is to go to the Javascript source (which differs from device to device, in iphone for example, you can go to github and look at the javascript classes and see their exact parameters (you may have to dig into other parts of the source code to see exactly what is going on, but all of the code is pretty straightforward).
As for implementing a database, the best thing to use is the sqlite database built into webkit. Jonathan Stark's excellent book, Building iPhone Apps with HTML, CSS, and JavaScript, has a chapter on doing this.
The easiest way to implement a database is probably to use Lawnchair. It's pretty easy to use and out-of-the box probably does most of what you need (including searching). It's cross-browser, battle tested and degrades nicely through the use of adapters. There is an adapter for Blackberry, and a plugin that supports queries. Here is a quick example using the WebKit adapter, which is good for Android and iPhone, to show how simple it is.
<script type="text/javascript" src="Lawnchair.js" charset="utf-8"></script>
<script type="text/javascript" src="webkit-sqlite.js" charset="utf-8"></script>
// Open local DB connection
var lawnchair = new Lawnchair({table:'mytable', adaptor:'webkit'}, function(){
// Lawnchair setup!
});
// Getting some data out of the lawnchair database
lawnchair.get('my_data_key', function(obj) {
if (obj !== undefined) {
lastSyncDate = obj.lastSync;
dataList = obj.dataList;
}
});
// Saving to the database
lawnchair.save({key:'my_data_key', lastSync: currentTime, dataList: someData});