In my pursuit to write a Chrome packaged app, I am struggling to get my data synchronized to the app so that it can be used in offline mode.
My data lives on a server and I access it trough a restful service in this case I use.net MVC WebApi
What I have tried: Using Breezejs because of the easy offline capabilities ; the problem is that
window.localStorage
is not available in packaged apps, I did tried switching it out for IndexedDB but no luck.
I tried chrome.storage that worked great with the build in sync but it is not a big truck and that is what I need at least a 10tunner.
So my Question; is there a silver bullet that has some XMLHttpRequest implementations, that makes it easier to get data from a restful service, storing it to IndexedDB so that it can be used offline and when going online syncs the changes, that is compatible with packaged apps.
I know I must probably write my own but if someone already went trough all the hoops and complexities of synchronization that can guide me it will be awesome.
Have you looked at using the syncFileSystem API ?
As long as you are happy to sync your data into Google Drive, this api should meet your needs for not implementing sync code yourself and still working offline.
Related
So I have multiple clients using an app built in electron. The entire application is actually a number of electron windows that talk to each other. When I have an update for the client side code (html/js/css) I have to have them shutdown, and run a utility that downloads from our internal server to update their app. I would like to know if there is a way I can either push new code to the clients (maybe through a socket) to overwrite the old code, or even maybe poll our 'code server' for updates, and then have it automatically update/overwrite existing code.
Is this possible? Is there functionality built in to electron that allows this?
And, if possible, how can it be accomplished? i.e. is there a library I can look at that will help me?? (i found a filesaver.js library, but its not exactly what I need). Thanks in advance.
You can have your Electron app load all code from a server every startup and cache this locally. You can do this by simply hosting your electron code on a web server and pointing Electron at the URL. You could make the app work offline by using a Service Worker.
This isn't a great idea though as code loaded from the internet will have access to all the node APIs. You will have essentially made a DIY botnet and securing it from abuse can be tricky.
You should read Security, Native Capabilities, and Your Responsibility in the Electron docs and be sure you understand the implications.
You can use the built-in autoUpdater of Electron: https://electronjs.org/docs/api/auto-updater
You need a server the autoUpdater can talk to, to download the updates from. The updates are installed after download.
You can host a server by yourself or use a service like https://www.update.rocks/
What you need is electron updater and you can use electron-builder for that.
Since CodenameOne doesn't support "the cloud storage API" any more and the parse.com is going to retire soon as well. Does CodenameOne has any plan to release a new Cloud Storage API or provide suggestions/guidelines to help developers to deal with the parse4cn1 library code, cloud code, database structure and data in parse.com?
That is something you will have to figure out yourself as parse4cn1 was initially contributed by a community member and wasn't developed by Codenameone team.
You can use a simple webservices created in php, python or java, hosted along your content with any ISP.
You may also have a look at amazon aws which is promising, they provide a cloud solution but their SDKs is not yet integrated to Codenameone.
I made the parse4cn1 lib and I'm also wondering what's smartest to do. With the announcement of Parse.com's imminent shutdown, there's been a lot of discussion around alternatives. My feeling is that "the dust is yet to settle" as per what options are best and reliable for the longer term (it would be a pity to migrate to another service only for it to be shut down soon). So I personally plan to wait till sometime in Q2 to do a proper evaluation of the alternatives. Hopefully, there'll be more clarity then.
The option to host one's own Parse server (e.g. on AWS or Heroku) is getting interesting. They recently announced support for push notifications on iOS and Android. If (when?) they open source the Parse.com dashboard code, I think that option would be much more interesting.
At some point in the coming months, I plan to make a parse4cn1 release that exposes an option to set the server path. With that, anyone migrating to the Parse server option should, in principle, be able to continue to use the cn1lib. Of course, for features that are supported by the open source Parse server.
PS: Here are pointers to some of such discussions on Parse alternatives:
https://github.com/relatedcode/ParseAlternatives
http://www.slant.co/topics/5219/compare/~firebase_vs_kumulos_vs_kinvey
I'm contemplating to use Parse as a platform for my app, as I'm trying to avoid creating and managing the cloud infrastructure myself.
For the sake of simplicity let's say that my app will hook into an Exchange Server and will need to leverage some hosted Machine Learning service to categorize my e-mail and report on insights found.
I'm assuming that Parse would store my core data, while the hosted ML will store the "Big Data" associated with processing for insights.
I'm also expecting my app to receive push notifications generated by the hosted ML service.
Does this sound like a plausible way to go about it and leverage Parse, or am I better off developing the backend myself?
I think parse.com is the right place for you requirements, because they have everything you need like storage of core data, push notifications, cloud module which can be integrated with heroku, social integration, user management functionalities.
They also have large set of client libraries for desktop and mobile apps (node,java,.net etc...) also they have libraries of embedded devices.
The biggest advantage is that everything is setup, and you are focused on software development not on infrastructure things. This is my opinion.
I've been experimenting with the above stack and so far was really impressed. Seems like a viable path forward. The Cloud Code capability of Parse is very solid, and easy to work with. If you want to run services outside of Parse code this us also possible : just issue REST calls.
I'm using Parse.com SDK services for my Android app.
I've seen that Parse had released their Android SDK as an open source project on Github on this address.
My app is almost finished, and when I'm uploading it to the Play Store, I don't want to be controlled by Parse.com (I mean that I don't want to be blocked someday, or I don't know that), so I want to move my whole database to my own server that hosted on a secure company.
I've checked the open source project on Github and realized that all I need to use it on my own server is to generate an Application ID and a client key.
So I want to ask if someone knows how to generate an Application ID and a client key of Parse to use it on my own server, or that you maybe knows another way of moving it to my server? And one more question: Today I'm using also Facebook SDK with my app. If I will move my database to my own server, will I still be able to use Facebook SDK on my app?
Thanks!
I have write an article about how to migrate parse to a custom server.
https://medium.com/#jcminarro/run-parse-server-on-your-own-server-using-digitalocean-b2a7d66e1205
There's a massive difference between Parse open-sourcing their SDKs compared to revealing their entire backend architecture and its configuration.
The open-sourced SDKs are essentially wrappers for Parse's REST API along with some convenience functions and logic for natively interpreting the JSON data Parse is transmitting.
At a high level, Parse uses MongoDB for its core database and is entirely hosted using AWS (Amazon Web Services). The entire architecture is highly complex and is not something you could just drag and drop onto your own software stack or hardware backend.
To help give you a better idea of how Parse achieves all of their services, here's an interesting presentation their Dev Ops team gave at an AWS convention. Suffice it to say, hosting the backend services for over 180,000 apps requires a complex infrastructure and that is the "secret sauce" so to speak for Parse and is why Facebook purchased them for over $85 million two years ago.
I have a desktop application which uses flat files (some xml and small pictures) as data. I want this data to be available on other PCs which have the desktop application installed and usable by a smartphone client (WP7 at the moment) as well.
The user should have it very easy to synchronize this data. He should be able to use accounts he already possesses (Live-Login, Googlemail, Facebook,...).
I thought about using Azure Blob Storage to save the data in Azure, the Sync Framework to perform the actual synchronization and the Access Control Service to handle authentication.
I have not used any of this technologies before so any advice would be great but I'm searching foremost for errors or shortcomings in this strategy I don't see yet. Is this approach viable at all?
Windows Azure is basically a virtualized datacentre. It is elaborate and complicated and is pitched at corporations who don't want to own their server infrastructure or hardware.
If I understand correctly, what you want is a cloud fileserver, not a whole LAN. Windows SkyDrive fulfils this requirement nicely and offers 25GB of storage per member with no charge for membership.
About Hotmail and Windows Live People often confuse Hotmail and
Windows Live, because when you set up a Hotmail account it uses
Windows Live for authentication and therefore you end up with a
Windows Live account and all the associated facilities, including
SkyDrive. However, it is entirely possible to set up a Windows Live
account using any email address as the username.
If you do this, it is important to be aware that the Windows Live
password associated with a given email address is completely
independent of the password required by the mail server that hosts
mail for the account. This can cause a great deal of user confusion.
For Hotmail (or any other mail server that uses Windows Live for
authentication) they are guaranteed to be the same password.
There is no official Microsoft framework support for SkyDrive. There is an open source project called SkyDriveApiClient, but it only works with the full .NET framework. I tried porting it but the author was a bit of an architecture astronaut, and it is absolutely riddled with [Serializable] which is not available on WP7x.
The WP7 guys have said that the WP7 framework will probably include support for SkyDrive but not in Mango (WP7.1) and given that Microsoft's typical release cycle is 18 months and Mango has yet to hit the streets, I'd say it will be two years before you can count on intrinsic cloud file services for WP7.
Roll-your-own wouldn't be hard, WCF services are dead easy to use from WP7. But that's not really cloud since you have to provide and maintain the server infrastructure yourself. For this reason and given the MS timetable, I have put a great deal of effort into producing my own SkyDrive client for WP7. Core functionality is complete and I am now refactoring, improving robustness and adding performance enhancements like local cacheing of tokens (cookies, essentially). I don't intend to release it; I have a number of apps planned that depend on this functionality and it suits me fine that there is a substantial barrier to competition.
I didn't tell you that to tease you. My point is that I'm so sure SkyDrive is the right answer that I put a lot of work into making it happen.
Cloud file storage is a perfect fit for mobile devices.
Azure is not a good answer for the sort of phone apps individuals want because the data store isn't shared in a way that required indexing or supports high levels of concurrency
I can certainly think of corporate phone apps that would benefit from using SQL Server as storage
Azure can do file services but it represents an ongoing expense. Nobody's going to put up with that when Google and Microsoft both give away web based cloud storage.
I can personally attest that if you're determined, it is possible to use SkyDrive from WP7.
Cloud storage is the only way you're going to get programmatically accessible storage that's shared by your user's mobile device and his computer. One of the things I intend to do that depends on shared storage is write a Silverlight app that lets you prepare map routes with multiple waypoints on a desktop computer and a companion app that uses them on WP7.
The Windows Live team has released what they call support for WP7. They supply a sample project showing you how to instantiate a browser object and load their login pages and manipulate them to log in and use their javascript API to manipulate SkyDrive.
This has one big advantage: browser cookies and cached credentials. The disadvantages are obvious; technical shortcomings notwithstanding the Windows Live team seems to think the only thing people want to do with a phone is tag their photos and fiddle with social media.
I have finished my own libraries. They do not support most of the social media twaddle. I have treated SkyDrive as no more or less than a cloud file system, providing
Authenticate(username, password)
CreateFolder(folderpath[, blocking=false])
Delete(fileOrFolderPath[, blocking=false])
SaveString(filepath, value[, blocking=false])
LoadString(filepath)
I could handle binaries but Convert.ToBase64 makes this unnecessary and strings are convenient for XML. CreateFolder, Delete and SaveString are optionally blocking. LoadString is always blocking because it's a function that returns the loaded string. CreateFolder is recursive so you can create an entire path in one call (eg /folder1/folder2/folder3). Calling CreateFolder on a pre-existing path has no effect, and SaveString uses CreateFolder to ensure the path is valid, making it unnecessary to create a filepath in advance. Authenticate loads the file system (except file content) into memory eliminating server chatter. This is asynchronous and a FileSystemReady event announces when the file system is completely loaded. The model is maintained as you add and remove files and folders.
This was a lot of work and no one reponded to my attempt to make it an open source project so I'm not inclined to give the fruits of my labour away, but provided your plans don't compete with mine I could be persuaded to come to an arrangement.