Summary of mobile phone application and mobile server development

I. About user data storage

First, in registered protocols, define the following public transport fields:

Version: This is actually a versioncode configured in XML. Versionname personally think that there is no need, so do not preach.

channel:  The user channel, which is shared with the Umeng_channel in XML, because Umeng is used all the time, so the definition is clearer.

device_id: Device ID

OS: Operating system type, where default incoming Android

Os_version: Operating system version

for small amounts of data, user data stored in MySQL is relatively OK, here's a direct example of Django's model:

code is as follows

copy code

from django.db import Models Class User (models. Model):     device_id = models. Charfield (max_length=255, Null=true, blank=true)     Version = models. Integerfield ()     channel = models. Charfield (max_length=64, Null=true, blank=true)     OS = models. Charfield (max_length=64, Null=true, blank=true)     os_version = models. Charfield (Max_length, Null=true, blank=true)     create_time = models. Datetimefield (default=get_cur_time)     login_time = models. Datetimefield (default=get_cur_time)

If you need to use federated logins such as Facebook, for small services, I personally prefer not to break the user's definition, because after all, it's hard to predict when this joint login will be added:

The code is as follows	Copy Code
Class Fbuser (models. Model): # Facebook User ID UserID = models. Charfield (max_length=32, Unique=true) # user.id, there is no foreign key here, it is to split the table or change the data storage to leave the posterior NATIVE_ID = models. Integerfield (default=0) def __unicode__ (self): Return '%s->%s '% (Self.userid, self.native_id)

Other business-related field definitions are determined by the business itself.

I am not very recommended in the future may be very large table of data use foreign keys, because it is likely later to design to the sub-Library, or migrate data to Redis, MongoDB, and so on, which I have mentioned in previous posts, we are interested to see.



Two. On the choice of communication protocols

Actually, there's a lot of things to say about this piece.

HTTP

The simplest is certainly the HTTP protocol, but the HTTP protocol in mobile applications can only meet the traditional demand, even with the technology such as long poll, after I tested, when the 3G network, operators often forced to return HTTP request for 502 error.

WebSocket

Of course, if the HTTP or heart, you can use WebSocket, tested websocket or more useful, Cocos2d-x has a dedicated WebSocket package, Android also has a special WebSocket library: Androidasync

Python also provides a lot of WebSocket server and client. For example, there are gevent-websocket on the server side, and Flask Plugin:flask-sockets developed on its base. Of course Django can also use Gevent-websocket directly, and Django has a version that is not based on gevent: Django-websocket. The client side has websocket-client.

Based on the gevent of the server before the test, you can normally receive a broken link message, logical processing is also more normal. The final point is that he can seamlessly integrate with existing HTTP servers without having to communicate across the two-server process.

Socketio

I have tested this, but it is not recommended to use in the project, he did too many compatible things, and our client is not a browser, there is no need to consider so many things, as long as the use of a protocol can be.

The other thing is, I tried the Python socketio server seems to have a problem, the server side does not receive the event when the client actively close the link, and only the client sends the Disconnect command to trigger the server-side related events. This thing looked up on the internet, it seems to be the official deliberate processing, to prevent the browser in the refresh triggered some strange things, but this processing for me is unbearable.

However, the relevant links are sent to you, you can try. Android client: or Androidasync. Python server-side: Flask-socketio,django-socketio,python client: Socketio-client.

Native socket+ Custom protocol

The flexibility of this approach is certainly the highest, but the corresponding development difficulties will certainly increase. The protocol can use JSON or Google Protobuf. This may be one or two words still not clear, the next one we devoted to spend space to talk about.