Is anyone here an "overall developer" ?

[greenace92]

I just made up that term but what I mean by it is a person who can develop application/software for both computers and mobile... specifically joining an android application wtih a desktop (linux and windows) program that both have access to a mysql database. I have picked up the term RESTful and SOAP as potential solutions to the phone and server part... C,C++,C#,VB,XML for the desktop app part.

 

The basic requiremetn is read/write from a MySQL server from both devices. I've recently started to work on Android Studio but am pretty far... does anyone want to take a stab at a basic read/write interface for both parts. Bare bones simple window/box UI, black and white...

 

This is a pretty time consuming thing for me... a lot to learn I'm essentially looking for a crash course introduction if anyone is up for it.

[scootstah]

You don't want to connect directly to the database from your mobile app. You'd definitely want to go through some kind of service such as a REST or SOAP API, like you mentioned.

[QuickOldCar]

Depends if your application is going to require an always online connection or work offline just within that device.
Could even make one that does local data storage when offline and syncs when is online.

Platform Software:

As you can imagine if doing only offline will be a lot more coding work for each specific device if are not using a cross-platform software.
If that seems like a lot of work to you...imagine also maintaining that code in the future for all devices.
Frameworks come and go, sdk's change, new operating systems or even updates, you may want to modify your application.
Multiply all that work for every device you want to support, yeah becomes a nightmare depending how complex your application is.
Most sdk's are either java or some renamed javascript based framework.
I'm the type of person that sticks to the popular and should be around a while more, with that said some good choices are to do it with C,C++,QT,GTK,Python

Let's say your application requires an online connection, is something using web based data and otherwise is a useless application.

Now instead of the device software doing the grunt work and requiring more coding, can have a remote server with an api that does client -> server, processing/data manipulation -> client. In your application could simplify the coding by making a gui a client can interact with, connect to api, use the server data however your application intends to, display to client.

API:

I am going to write this and link to some items so even a beginner knows what I am talking about.

 

REST : Representational state transfer

(my simple definition)

Uses url or uri over http web

The data set to be retrieved could use the url,uri or any query parameter and or their values to access a particular data set.

Can use GET, PUT, POST, or DELETE http methods

Do local server actions with them or send out a response to a client or server.

You can literally return any type of response you want, some popular ones used in api's would be json,xml and html

The format of the response can also be determined by a url parameter in the query, such as format=json,format=xml,format=html

 

XML-RPC :

(very old)

remote procedure call using xml to encode and http transport

 

SOAP :

(very basic summary)

soap evolved from xml-rpc

xml based

Has an envelope for defining the message structure and how to process it.

Encoding rules to determine each instance of application data types.

A method to handle procedure calls and responses.

Uses HTTP, SMTP, TCP, UDP, and JMS transport protocols.

 

 

 

Here is my opinion, others may have different preferences or advice, that could be their opinion.

If application is web based, the current and future of the internet is a server with optional cloud based storage using an API  incorporating CRUD  (SCRUD,CRUDL,BREAD,DRULAB) using REST and JSON data using a request-response over http.

If you want to use different methods other than mentioned above that's your choice to do so.

API response types could be html,json,xml or solely json and the api or (*)-application can use that data or easily convert it to whatever you need, even your website using the same api internally or externally across a network.
Nearly everything can work using json.

Through the api you can use various header fields

To me just using json or a single data type has an advantage, you know is just one type of data in your applications. Also is useful when comes to caching.

 

You can have a public or private api.

Items such as user log in, public and private keys, tokens, domain restrictions, paid subscriptions, access restriction.

A lot of people use oauth, I make my own.

 

There would be a programming language (list) at the server for processing.

Data storage:

Your application may not require any data storage, does some processing in the application or at the server and returns live results.

 

Could use a database at server or in the application

Application based storage, locally stored in the operating system a database such as sqlite or flat files

Browser based storage using sessions, cookies, local storage

 

With sessions the client does not have the ability to change the data.

Using sessions forces the client to log in each time because they get lost expire times and garbage collection.

It's possible to use a combination of sessions and cookies to keep that user logged in longer, although I would lean towards creating an access token instead.

Cookies were useful a while, many people are blocking them now.

Depending what country are in such as the UK, you are in have to supply a warning are saving their cookies and they accept it.

There are cookies and also html5 has web storage

localStorage

http://www.w3.org/TR...orage-attribute

localStorage can store 5 mb versus cookies having a limit of 4095 bytes per cookie

Cookies are primarily to be read server-side while localStorage is meant as client-side only

If localStorage is saved from a secured ssl such as https it doesn't work for non https

If your server needs to read from localStorage and is lots of data it's not worth sending the data back with javascript/ajax in the HTTP header or like in hidden forms

localStorage has no expiration date, it only gets removed via javascript, clearing browser cache or the browser is closed.

 

There is also sessionStorage

http://www.w3.org/TR...orage-attribute

When a new HTMLDocument is created, the user agent must check to see if the document's top-level browsing context has allocated a session storage area for that document's origin. If it has not, a new storage area for that document's origin must be created.

 

localStorage persists over different tabs or windows, and even if we close the browser, accordingly with the domain security policy and user choices about quota limit.

 

Leaving the tab or page were on sessionStorage is gone while localStorage can remain.

 

Cookies, localStorage and sessionStorage can easily be read or changed from within the client/browser and should not be used for storage of secure data.

There is attempts modern browsers to prevent Cross-Site Scripting (XSS)/Script injection by setting an HTTP only flag... but I wouldn't rely on it.

If you are not using SSL, cookie information can also be intercepted in transit, especially on an open wifi.

 

If you want to save a pile of information and is just for the clients purposes, localStorage is the best way.

If is some sort of temporary data just for a user that page then sessionStorage

If the data is to be used for your own server then normal cookies is a better way to go.

 

Summing it all up...it's better to use sessions unless is not important data.

Edited September 11, 2015 by QuickOldCar

[greenace92]

This is a lot to take in. I have to actually make soemthing then come back with my results. Thank you for your time and the information.