I am building a webapp that cannot be put into the app store (security reasons). The webapp needs access to more data than can be held in localStorage or other offline-storage means (let's say up to 1GB of data).
My idea of a solution is to code up an HTTP server for Android and iOS, and then get/post data with AJAX so I can have access to the device's internal storage.
My question is,
Can this be done on iOS and Android?
By 'Can', I mean both technically (is there API access to the required components, and can it be always running in the background) and legally (is it consistent with the terms of service of both the App Store and Android Marketplace).
I don't know much about either platform and the capabilities, but I could figure it out if I was confident that it is possible.
The reason for this is so that large amounts of data can be made available all the time to a webapp, regardless of the presence of wifi or a cell-tower.
Yes
Android examples: How to create a HTTP server in Android?.
iOS examples: iPhone HTTP Server.
For a full app that uses an http server, check out Websharing on Android.
Related
I want to ask about the security of web application.
I'm developing on web site for an inventory management system by web service.
And wrapping as android application with the webview.
But my client ask the website can be opened in android application only.
I think it is possible with agent header when web server response to request.
But it just a makeshift.
So is there any way to check the website is opened in browser not authorized application?
I used spring boot for web server.
This is not possible. Once you expose an endpoint publicly, you can always try to connect to it with whatever software supporting the protocol (or an analyzer which will reverse-engineer the protocol).
This said, you can make it difficult by obfuscation.
One solution is to use information provided by the client (browser in your case). This is usually the agent header (as you mention) but can also be some fingerprinting. You could for instance detect the size of the screen and make some decisions from there on.
Another solution is to use some secrets (better call them "secrets") to show the backend application (or API) that some specific code is calling. I can imagine that you could bundle the HTML/JS/CSS code in your application, together with a key so only the application owners will be able to send a recognizable traffic (recognized by the backednd).
All of this is more or less difficult to crack but with some layers you will get rid of at least some population which would like to access the site via other means than an app.
I want to develop a system in which data is being shared between DESKTOP app and Android app.
After searching I have found that I need a server in between them. But I can't figure out what the server is? How do I create it? And how will it help me connect my two platform devices?
Desktop App will receive data from android app. And manage data. It will also be used to send notifications/messages to android apps.
Android App will be used to input data and send it to desktop app. It will receive updates/notifications from desktop app.
Now how do I connect these two? I basically need a common database for real-time data sharing and notifications.
Edit: I am building the desktop app using C# and android app using Java.
Edit2: Maybe I can host the database on CPANEL or 000webhost using PHP. And then connect it with both android and C#. Is this the correct way to do it? Is it possible to connect it with C#? I know it can be connected with Android, not sure about C#.
You don't necessarily need a database. You need a common network protocol between two applications.
All network communication is done via sockets. You need a library that allows you send data over sockets. For example, here's an Android guide that is about sockets.
A socket binds to a specific port of a computer, essentially making it a "server". Much like how web servers all expose port 80, and communicate over a protocol called HTTP. Which is important because it is up to you to decide what protocol your applications communicate between each other, because the socket just sends bytes - it doesn't care what you send or how, as long as it travels to a port on a particular server. It also won't parse the data for you, that's up to your application to handle. For example, how would your desktop app know the Android device sent it a text message, or some image to be displayed, or an address to show a map?
All in all, your reason for wanting a desktop application rather than a web application is not entirely clear. Parsing only the body of HTTP payloads from different HTTP paths that are mapped to different methods (which is typically referred to as a REST API) is much simpler than building your own protocol. You might as well build a desktop GUI over top of a web server.
Making the desktop app send updates back to your mobile application is basically impossible using a bi-directional socket architecture. Your Android should not be running an open server socket continuously just for your application, mostly because battery drain, but because its network address is subject to change frequently, and you therefore additionally need a registration server from which your device would reconnect to. Such a service exists as Firebase Cloud Messaging, which is a rebranding of the GCM technology made by Google, and it can be used to send push notifications to devices, but only with small data payloads.
See here about what activities occur on an Android device for notifications. How does push notification technology work on Android?
Back to the question about databases. Suggesting one to use is too broad. And you only need one of those if you want to store and/or query or join datasets. The same computer running the desktop app can install and run whatever flavor of database you prefer, whether it's a relational database or noSQL database, entirely up to you. The only realtime databases I know of are RethinkDB and Firebase.
You could also just hold a SQLite file which is as good as a small scale database (even the SQLite documentation recommends it for low traffic web sites).
Firebase supports web interface, so you can develop html code and integrate in desktop app, something like web integration in windows form application
We are looking to rewrite a form-based application with a fairly tight time-scale (ideally, we would be launching the beta mid-July, and the final version by September). The current platform is showing its limitations and would require an exorbitant amount to bring into line with our requirements. As such, we are looking to bring the technology in-house, and writing our own solution.
Requirements:
Must be able to handle loss of network connectivity - the user may not always have internet access
Must have secure two-way communication with the server - the information being uploaded and downloaded can contain personal information, and it is imperative that we not be responsible for data-loss
Must be able to synchronise and update / remove records already on the tablet - the information can change, and the user must have access to information as "fresh" as possible
Must be able to store a large number of records (~1000+ records, a few kB each, so total 5+ MB) offline - depending on the tablet model, the user may only have internet access via wifi at the beginning and end of a day, so as many records as might be accessed should be downloaded and stored
Should be accessible on both iOS and Android
The solution we have currently is a form app, which fails heavily on point three, which is rapidly becoming a deal-breaker. The solutions that have been floated are:
An HTML5 website with offline capabilities, through the tablet's web browser
A website wrapped in an off-the-shelf app "shell" to provide offline capabilities, deployed through the app stores
A custom-built app (through Xamarin or similar) to be deployed through the app stores
Unfortunately, we are a company of desktop developers - we have no in-house experience with tablet applications currently. That being said, the application is tied very closely with several of our other products, so it would be difficult to outsource the development.
The question, therefore, is this:
As a mobile application developer, what approach would be "recommended" to build an offline-capable app that must communicate securely with a server when it can?
So for 5 mb of data that needed to be synchronized, I would build an web service from where you can get the data for your mobile application.
I prefer JSON Format for the data.
When your app logs in while internet connection, the app can fetch the complete data from the web service.
What I do then, is to compress or archive the json as file to the app internal filesystem.
Now there are only two scenarios for the app:
offline (login):
get the archived json file and do what you want with your data
online (login)
fetch the data again from the web service, archive it and then do what you want with your data
To synchronize the data back to the backend is not really mobile application stuff. You have to think about your architecture in the backend.
For security ensure you have ssl enabled for the connection to the web service.
I am native iOS developer but I build something similar with Symfony as Backend and three native applications (iOS, Android and Windows)
You could also use firebase as a backend, it really depends on your needs.
At the end, im just a stranger from the internet :) and normally when a customer needs an estimation, we really need time for such an estimation and to choose the right platforms that fits for the customer.
I am new to Android and taking the risk of doing a final year project of building an Android app. I would like to know whether I can create Client-server architecture application in Android. I'd like the front end to be the mobile app. Also, where do you store data (I don't know where to store data exactly) at back end.
Use Restful web Services with json(Ex: WCF in the backend with Sql Server)
For Mobile App, These are useful tutorials http://developer.android.com/training/index.html,
http://www.vogella.com/tutorials/android.html.
Very many, if not most, existing Android apps retrieve data over the Internet and display it (e.g. the StackExchange, Yelp, or Facebook apps). They are clients requesting data from servers and therefore fit into the definition of being “client/server”. I'm hard-pressed to think of an app on my phone that isn't a client to some kind of web service.
If, as your question suggests, you are using HTTP for client/server communication, there is no reason why the client platform (Android) should have any impact whatsoever on the server-side implementation. In the wild, Android clients are served by servers implemented with every conceivable combination of OS, language, and database. Therefore “where do you store data?” is an unanswerable question, as the answer depends entirely on implementation choices that you make on the server side.
I am trying to develop a system that involves a:
server with a database that will handle the system's logic and manipulate data
an android app that will interact with that server (pull and push data into the server)
a website that will do the same as the android app, but from a website with slightly different data.
What I thought of is to use SQLite with Apache Tomcat installed on the server and deploy a Grails war file on it. That will take care of the 'website' side of the system. But what about the android app? Can it communicate with Tomcat as well?
Tomcat will suit your needs. I would look at hosting options though. Are you hosting your own server, or do you have a hosting provider? Do you have experience hosting a tomcat server etc. Do you have experience with java web applications, or other web frameworks? All of the above, and probably more should lead you to your decision on what type of framework/language to use on the server. This in turn will lead you to your options for hosting, and web-container to use.
Once that is determined all major web frameworks will allow you to publish web-services Rest, Soap, etc. that can be consumed by an android application.
Also, if you are planning on providing a web interface and service at the server level, my guess is you are going to be storing a fair amount of data, I would look into a more robust and scalable database such as mysql or postgres. This post contains some insights into this.
If you have an API that is web accessible, an Android can access it.
Android shouldn't have any problems communicating with Tomcat.
Look at http://grails.org/doc/latest/guide/13.%20Web%20Services.html for more information.
A RESTful web service is most likely what you'll need. Android can consume SOAP web services but it requires more work for less overall functionality.