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});
Related
We're designing a system for a client where they are allowing authenticated users to upload images. We've created an API to upload the files but the client only wants the latest file and delete all previous ones so that there would only ever be one.
We've looked through the docs and can't come across a way for ADAM to handle this in both 2SXC and DNN's file system.
Internally when deleting images we see API calls like the following to the internal 2SXC API, but we're wondering if this is exposed somewhere within the public API?
https://somedomain.com/api/2sxc/app/auto/data/61393528-b401-411f-a001-f423ea46700a/b7d04e2c-c565-496c-8efb-aa133cf90d33/Photo/delete?subfolder=&isFolder=false&id=189&usePortalRoot=false&appId=3
We could probably use the same endpoint above, but we'd likely run into permission issues or changes to the APIs that could be problematic.
Thank you for any advice you can give! Perhaps #iJungleBoy can provide some thoughts on this.
As a solution from a completely different direction, if you are on the later release of 2sxc (v12.8+, v13+), and comfortable programming in C#, you might consider doing this as a "cleanup" from a Dnn Scheduled Task. This can be done with a relatively easy setup. We have a Gist in place that we use as a starter. You simply put the code in the /App_Code folder then setup a normal Dnn Scheduled Task. NOTE that you can scroll down to the first comment on the Gist to see a screenshot of a complete working setup.
Accuraty's AccuTasks template on GitHub Gists
There are two more key things to note:
You need to install Dnn's CodeDom 3.6 because the example uses the later versions C#'s string interpolation - OR remove the few $"ASL2021 - {this.GetType().Name}, Task Scheduled Email", bits or convert to string.Format() or something.
Since your task's code is NOT running in a (2sxc) module, if needed, you'll do stuff like this: 2sxc Docs - Use 2sxc Instance or App Data from External C# Code
So, if you are comfortable writing code that "finds and deletes stuff older than NN days" - this might be the way to go.
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.
Is there any way to auto-generate Swagger documentation (or similar) for a Nancy service?
I found Nancy.Swagger, but there's no information on how to use it and the demo application doesn't seem to demonstrate generating documentation (if it does, it's not obvious).
Any help would be appreciated. Thanks!
In my current project I've been looking a lot into this problem. I used both nancy.swagger and nancy.swagger.attributes.
I quickly discarded Nancy.swagger, because for me personally it doesn't sound right that you have to create a pure documentation class for each nancy module. The attributes solution was a bit "cleaner" - at least codebase and documentation were in one place. But very fast this became unmaintainable. Module code is unreadable because of many attributes. Nothing is generated automatically: you have to put path, all parameters, even http method as an attribute. This is a huge effort duplication. Problems came very fast, a few examples:
I changed POST to PUT in Nancy and forgot to update [Method] attribute.
I added a parameter but not the attribute for it.
I changed parameter from path to query and didn't update the attribute.
It's too easy to forget to update the attributes (let alone documentation module solution), which leads to discrepancies between your documentation and actual code base. Our UI team is in another country and they had some trouble using the APIs because docu just wasn't up-to-date.
My solution? Don't mix code and documentation. Generating docu from code (like Swashbuckle does) IS ok, but actually writing docu in code and try to dublicate the code in docu is NOT. It's not better than writing it in a Word document for your clients.
If you want Swagger docu, just do it the Swagger way.
- Spend some time with Swagger.Editor and really author your API in
YAML. It looks all-text and hard, but once you get used to it, it's
not.
- Spend some time with Swagger.Codegen and adapt it (it already does a fair job for generating Nancy server code and with a few
adjustments to moustache templates it was just what I needed).
- Automate your process: write a couple of batches to generate your modules and models from yaml and copy them to your repository.
Benefits? Quite a few:
-
Your YAML definition is now the single truth of your REST contract.
If somewhere something is defferent, it's wrong.
Nancy server code is auto-generated
Client code-bases are auto-generated (in our case it's android, ios and angular)
So whenever I change something in REST contract, all codebases are regenerated and added to projects in one batch. I just have to tell the teams something was updated. They don't have to look through some documents and search for it. They just have their code regenerated and probably see some compile errors, in case of breaking changes.
Do I still use nancy.swagger(.annotations)?
Yes, I do use it in another project, which has just one endpoint with a couple of methods. They don't change often. It's not worth the effort to set up everything, I have my swagger docu fast up and running. But if your project is big, API is changing, and you have multiple code-bases depending on your API, my advice is to invest some time into a real swagger setup.
I am quoting the author answer here from https://github.com/khellang/Nancy.Swagger/issues/59
The installation should be really simple, just pull down the NuGet package, add metadata modules to describe your routes, and hit /api-docs. That should get you the JSON. If you want to add swagger-ui as well, you have to add that manually right now.
No. Not in an automated. https://github.com/yahehe/Nancy.Swagger needs lots of manually created metadata.
There is a nice article here: http://www.c-sharpcorner.com/article/generating-api-document-in-nancy-using-swagger/
Looks like you still have to add swagger-ui separately.
I've been tasked with developing an application for internal use in our company, the end-users being the operators of the call center and their superviser.
There would be therefore be two types of users: operator & supervisor.
The operator view would be purely passive: ability to see their monthly goals (calls taken, calls answered etc) as well as those of their "cell"(group of operators+supervisor) and other "cells" and that's it.
The supervisor one however would be able active: they need to be able to set monthly goals for their subordinates as well as view them.
The application needs to live in the browser, and that browser is...sigh, either IE6 or IE7. So my question is, should I use something client-side like backbone.js, or something server-side like, say, Code Igniter?
I need to be able to develop it in a short time frame and add features as requested.
Any advice is greatly appreciated.
Thanks.
Firstly, IE6 is very old. It is still supported but support will end fairly soon (about a year, I think), so your company needs to have an upgrade plan in place. IE7 has a bit longer to run, but will also fall out of support at some point. Your company must make plans for an upgrade process. And you need to make sure that anything you write today will continue working on upgraded browser versions when they come.
Okay, that aside, today you need to support these browsers.
The first advice I would give is to use jQuery for all your Javascript needs. It is specifically targeted at being compatible with IE6 and above, and it hides a lot of the complexities with cross-browser and old-browser support from the developer, but also works well with newer browsers too.
IE6/7 do have a number of serious bugs and omissions in their Javascript support, but these can generally be worked around. Using jQuery will mean you can forget about most of them.
In the main, I would recommend against using a client-side framework like Backbone. Stick with server-driven simple HTML pages. Maybe a bit of ajax using jQuery, but nothing too much more than that. IE6 and IE7 are very very slow browsers, so the less work you make them do, the happier they'll be. Put too much Javascript on the front end and you could wind up with a system that is too slow to be usable. Also, a lot of modern JS libraries don't support IE6 at all. I'm not sure about Backbone, but even if it works now, you can't be sure that later versions will continue supporting it. (even with jQuery, some developers are starting to push for IE6 to be dropped. I don't think it'll happen just yet though)
Make sure you specify a valid <!DOCTYPE> for all your pages. Without it, IE will drop into quirks mode. This will make it very difficult to upgrade your site to a newer browser later on. There are many valid doctypes, but it doesn't really matter which one you use, as long as it's valid. Therefore, I suggest using the HTML5 doctype, simply because it's valid and it's short and simple: <!DOCTYPE html> -- that's all there is to it.
CSS is where you'll really have some pain if you're used to working with modern browsers. IE6 in particular has terrible CSS support. For IE6/7 CSS compatibility, I recommend using the Quirksmode.org compatibility charts to find out what does and does not work in those browsers.
Finally, make sure you read up on the well known IE6 bugs. There are a lot of them, and they often cause weird and wonderful rendering errors on perfectly valid code. Knowing about them in advance will help you avoid them, and help you recognise them when you (inevitably) hit them.
Hope that helps.
Oh, and good luck -- it sounds like you'll need it! ;-)
Developing websites or web applications for Internet Explorer 6 is possible as long as you do not use things such as HTML5 Javascript functions.
As for the live part, maybe you could use AJAX long polling or something similar. Example: http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery
Hope this helps!
I know it has great out-of-the-box features but is it easy to customize?
Like when I query stuff from the database or change css layouts.
Is it faster to create my own modules for it or just go on and write everything from scratch using frameworks like Cake
I'm currently working on an Elgg-based site and I absolutely hate it. The project was near completion when I stepped in, but the people who created were no longer available, so I took it over as a freelancer.
As a personal impression, you are much better off writing the app from scratch in a framework. I don't know if the people before me butchered it, but the code looks awful, the entity-based relationship model is wierd to say the least and debugging is horrendous. Also, from my point of view, it doesn't scale very well. If you were to have a consistent user base, I'd be really really worried.
It keeps two global objects ($vars and $CONFIG) that have more than 5000(!) members loaded in memory on each page. This is a crap indicator.
I've worked extensively with cake. With Elgg, for about a month in a project that is on QA stage right now.
My advise is: if you need something quick with a lot of features and you only need to customize a little, go with Elgg.
If you're going to customize a lot and you can afford the development of all the forums, friends, invites, etc. features, go with Cake or any other MVC framework.
I have been working on a Elgg site for the past month or so, its code is horrible, however it's not the worst I've seen :D. it's not built for programmers like Drupal is :D. But it's not too bad. Once I got a handle on the metadata functions and read most of the code I was able to navigate it well and create custom modules and such.
What would help immensely would be some real documentation and explanation of the Elgg system. I don't think that's going to happen though :).
Out of the box there are a few problems, there are some bugs that haven't been fixed for a while and I've had to go in and fix them myself. Overall, you can make it pretty and it has some cool functions, but i wouldn't dive in until i had read the main core code to get a handle on what's happening on the backend.
Oh and massive use of storing values in globals. and a crap ton of DB calls (same with Drupal though).
i wonder if the use of storing everything, and i mean everything for your site in the globals will really hinder the server if you have a massive user load.
If you want to build a product based on a social networking platform/framework then Elgg is definately a good way to go. The code is not that bad if you actually look before leaping and doing what elgg expects. You go against its processes and structures and it will leave you beaten by the side of the road.
Developing modules/plugins or editing CSS is easy and Elgg does give you great flexability to basically build your own product ontop of it. Dolphin, as comparrison, does not allow you to do anything outside of what it expects you to do.
If you however just need a framework (not primarily for social networking etc) with some user based functionality then i suggest Cake, or if your project is HUGE then maybe Symfony or Zend. They all have plugins you can download and use/hack which would be easirer to adjust for personalised needs.
To show what you can do with elgg here is a site Mobilitate we built with Elgg 1.7. This is a very complicated website and was built ontop of Elgg.
We are starting a new project with Elgg 1.8. The new version is a major improvement they have made a lot of elements easier, incorporated better JS and CSS implementation/structure and have better commented their own code.
Elgg's database schema is horrific. They've essentially implemented a NoSQL database in SQL. It completely defeats the purpose of using a relational table structure.
If you can ignore this, and aren't doing much customization, you might be OK with Elgg. If not, STAY AWAY.
I've been working with Elgg for over a year. It is easier to customize than it would be to build something from scratch using a framework like CakePHP. I tried CakePHP and found it even more complicated than Elgg.
It is difficult to query the database due to the entity-based relationship model. You should use the build-in methods for accessing data. However, I have written many queries to double check on what is actually stored in the database.
You cannot change layouts using CSS alone. You have to deal with the various Elgg views. But CakePHP uses the same Model/View/Controller MVC concept so that would be just as difficult.