Data storage best practice mobile application - xamarin

I am a junior Android Developer and I intend to develop a little cross platform with Xamarin.
This app is just a FAQ with an enormous amount of data which will not change in the time (additionally I would like to add a quiz). I want the app be multilingual and be accessible without Internet Connection.
My worry is about the choice of the method of storage of the data and the handling of translation. Which method should you recommend?

Related

Is Parse an adequate solution here?

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.

How to move Parse.com database to my own server and still use Parse.com SDK?

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.

Azure, Sync Framework and Access Control Service: Are there obvious shortcomings or problems in using this technologies together?

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.

Messaging app on the WP7

I was wondering if it is possible to develop a text messaging kind of application similar to WhatsApp, but for between WP7 devices? What difficulty programming skill level am I looking at and what would be required to develop such an app? Thanks!
In general I don't think it will be really difficult to build an app like WhatsApp. (Although I only heard about the funcationality) So I will give you the information I think you should have at a minimum.
In the first place you need your WP7 app, which I think should have push notifications to notify users about new messages. (Note: push notifications work in batches, so there will be no instant delivery notification to the end user.) You should have a login system in your WP7 app, which makes users uniquely identifiable.
Somewhere you should have a central datastore where you can store users, messages, relations between messages (replies, forwards, etc.) (Note: If your app becomes as big as WhatsApp you should have a really good scalable datastore.).
I would use WCF to communicate between your datastore and the WP7 app. Probably I have overseen something right now, but this will give you a start for defining your applications architecture.
UPDATE 12:54
As i saw your comment about where to start I searched for some documentation:
There is a free e-book from Charles Petzold which covers alot:
http://www.charlespetzold.com/phone/
Also there are a lot of code samples and documentation on MSDN:
Main overview of WP7 development:
http://msdn.microsoft.com/en-us/library/ff402535(v=vs.92).aspx
WP7 code samples:
http://msdn.microsoft.com/en-us/library/ff431744(v=vs.92).aspx
You can have a look at the Sockets Support section, which may help you to get started.

What is the best solution for real-time bi-directional communication between a web application running on a mobile phone and a server?

I'm looking at having thousands of simultaneous connections from mobile phones to the server whereby anytime a user interacts with his cell phone, the data is sent and logged by the server. Also, anytime the server has new information for that user, the server can push that information without a browser refresh. I am wondering what is more stable and how you would build this?
A good real-time framework or infrastructure will have numerous APIs that should let you connect any device, no matter the technology, to the real-time server e.g. an iOS client library for iPhone and iPad, a JavaScript client library for numerous platforms including normal and mobile web, an Android compatible Java library and so on.
An interesting idea might be to choose which ever framework or real-time service suits your needs best and then using something like PhoneGap. But, as #rt2088 says, it depends if you need the notification app to be running as a service on the phone or as a standalone application.
The choice will also depend on whether you want to install, host, maintain and manage the scaling of your own real-time services or not. If not, there are a number of services out there who you could use so you can concentrate on building your application. If you do want to manage your own infrastructure then the Comet Maturity guide could be a good start. It's a little out of date but is still probably the best reference available.
the ability to push new content the
user based on his GPS location which
is "pinged" to our server. Based on
that, we deliver local content. What
frameworks are you talking about?
There are a number of real-time frameworks available at the moment. Some are hosted services and others require installation on your own hardware. The majority of them will come with a bunch of libraries in different technologies that make it easier to get up and running with them e.g. a JavaScript library that wraps the WebSocket object and also manages fallback for web browsers that don't support WebSockets.
I've just created a Real-Time Technologies Guide in which I've listed all the real-time technologies that I could think of and provided a bunch of tags associated with each.
wouldn't a javascript client library
cover all platforms if it is a web
appilcation?
If the application is a web application then yes, a JavaScript library would be all you need for the client application. The server side libraries that you require would depend on the real-time technology you choose.
Best solution to achieve this is to use the WebSocket communication. It is bidirectional asynchronous communication. Currently every browser supports this new standard and plenty of code snippets available. You just have to google it. There are many server and client side frameworks. choose the one best suits to your requirement.
The details of the WebSocket specification is available at -
Websocket specification
Do you need notification when user uses mobile browser of handset or the mobile handset itself (performing non-browser tasks)? Based on that, the framework to record user activity can be selected.

Resources