I have developed a few apps in my days, but only small local applications.
I want to start working on more advanced apps, and I have a few ideas that require me to keep track of usernames, scores etc, Online.
Lets say im looking for a way to keep track of usernames/passwords, making sure the usernames are unique, and updating the client sqlite database aswell as server database whenever they go online.
So far the only ways I can think of is creating a java servlet or posting and recieving data through PHP and into a MYSQL database. (which I have done some testing on... and I dont really like it).
What is the common/best way to do this? Can anyone nudge me in the right direction?
Essentially what you need is a web service hosted somewhere to perform the tasks you need, such as ensuring unique usernames etc.
I would suggest creating a REST service for this, perhaps look into JAX-RS for this, but any REST framework would suit you.
On the Android front, you would need a (de)serializer, such as Google's GSON which will enable you to convert Java objects to/from JSON seamlessly.
Finally, something like Square's RetroFit will make it much easier to call on that external REST api from your Android code.
These are just a few of the possibilities - there are alternatives to all of these libraries if you don't like any of them.
Related
I am working on an android app where I need to integrate data from another app.
Just For Example: Think a situation I have google play store in my mobile. Now when a person searches "education" in play store It shows all the result in list which consists that keyword. Now I want to get all the data result fetched by play store in my app.
Note:- I am not sure there is any code to get data from another app, but still I saw an app called App for all taxi cabs It shows all the result from various application even there is no api for ola cabs, Taxi for sure and many others but they are somehow manage to get all these data for their app.
Please help I crucially want to know if there is possibility to do so or not.
It sounds like what you want to do is "snoop" on another app. That is, you want to retrieve data from it that it doesn't publicly expose in it's API.
I believe this is generally impossible without breaking the encapsulation of the app - this means you would have to use more than its publicly documented (and reliable) interface, and delve into its implementation specifics which are liable to change without warning, thus breaking your own app.
There are apps that are able to take screenshots of other apps, this would be one example of how you could indirectly break the encapsulation, as you could attempt to parse the data that way. I give this example purely to prove that it is possible, however this would be considered terrible practice and should be avoided for many reasons.
For all serious use cases, I would say that if it is not provided in the API, you cannot obtain the data.
I am creating an image/graphics intensive application on android. Thus I have decided to keep images at server side and fecth them in batches when needed for each user. Apart from this I would like to manage some minor user data at backend for any future extension to the app or dynamic loading of some content.
For this I am looking out for the easiest but not a very rigid back-end solution. After some research I have boiled down to below mentioned options(In the order of priority):-
Amazon SDK for android :- It looks like this provides a lot of pre-built components but I am not sure how flexible it is when doing some custom back-end coding/feature implementation.
Parse :- Easy to understand and use but not flexible when it comes to custom feature development.
Amazon EC2 Java Backend:- I will have to do all the server side coding from scratch here but this will provide complete independence in feature implementations. Though I would love if I can find some code samples relates to user management, backend db management and java restful web services.
Any suggestions or pointers that you guys have in the above choice would be great
Thanks in advance
I have been using Parse but I haven't explored the other 2. So, this may not be a comprehensive answer but I would try to give you some pointers based on my experience with Parse.
I have been into Android development for quite some time now but I do not have any significant expertise (I would say very minimal) on the backend. Also, you mentioned you wish to work on graphics/image intensive application. As far as the application I use Parse for is more of user data and minimal images, (requiring extensive relational database).
Parse makes it really simple to create the backend structure. And the client SDK is also very powerful. Their API's are very straight-forward and doesn't require you to worry about writing complex queries, caching them and saving the data. Given my background as I mentioned above, I would say there is no learning curve involved into getting started with the dev. You can simply start building your app right away!
Also, Parse uses AWS S3 on the backend with Mongo-DB. So, I believe computation on the server side should not be a problem. Server side logic can be implemented using ParseCloud (requires some javascript). But, if you plan to write some complex algorithms, I am not very sure how much can that be done.
Documentation of Parse on Android is quite good to get through most of the dev. Extensive doc for iPhone dev.
As far as cost structure goes, it allows 1 million free API requests per month and this is very much sufficient to get through quite a number of users. In your case, the storage should be of more concern. Parse allows 1GB free and some 20 cents above per GB.
Hope this helps!
I am looking out for the easiest but not a very rigid back-end solution
Have you considered AppEngine? Here's a tutorial about how to get app engine working for you fast
You can store up to 5 GB of blob storage for free, should be more than enough for experimenting. If you go over you can pay the $0.13/GB/mo extra for blob storage, which is more than reasonable.
I don't know what kind of app you are doing, but I'll propose one approach.
Use https://imageshack.com/ for images.
Create your user saving data application with a lightweight webservice (REST+JSON)
and expose it at heroku (https://www.heroku.com/) with your prefered language/plataform.
It could be java or ruby.
Using imageshack for images will save cloud space for you and the service is quite fast.
I'm about to embark upon writing an android app which notifies the phone's user when an external mySQL DB is updated (add only) with a ticket so that the user can check if the ticket requires his attention (an attempt to reduce the buildup of tickets that he has to trawl through).
From my research, most questions suggest using a PHP web service with my program (written in java) and definitely/maybe/definitely not/it's deprecated using SQLNotification to fire the event. I've also seen something about some bloke called JSON and the brands of SOAP he uses.
What I've been unable to figure out is how all of these frameworks/toolkits/services/things work together.
My question is in two parts:
Is SQLNotification usable? If not, is there a simple way to check for changes (beyond the obvious answer of polling)
How does everything (SOAP, JSON, web service, app) fit together and have I missed anything on the frameworks front (Heard mentions of spring, hibernate, tomcat).
On my experience, I'm relatively fluent in Java, understand the basics of MySQL, am a beginner in PHP and haven't written for android before.
Thanks,
Ben
According to the information you have provided, seems like you have different options:
Push
If you want to go the push way, you will need some central architecture that can take notifications from the database and immediately send them to connected clients. It's not that easy to build such a scheme, would only recommend it if you really need immediate notification. As a start point, look at this sample: http://www.gianlucaguarini.com/blog/push-notification-server-streaming-on-a-mysql-database/
Pull
If you go the pull way (polling), you can have a service working on the phone wich polls every configured time. In that case you will need some stateless service, some simple JSON service would do great.
On both cases, be careful with security, you should secure your channel with ssl and have some decent sort of authentication.
I think a good rule of thumb is saying (it's just based on personal opinion/experience, maybe your decision path has other factors that you have to consider), if your pollig intervals don't need to be lower than 5 minutes, polling will do fine. If you need almost real-time notifications, you can implement the push architecture, but you have to know it will cost more efford to get it working as you have to take care of things like client disconnection, how to handle notifications if a client is not connected, get the real-time notifications from the database, etc.
Hope this helps as a starting point,
I'm planning to write in JAVA simple, but easy to develop in future MMORPG. I know more or less how it should looks like, but I have some questions:
Which kind of data should have client? I know that, for example, server informs client if "that field" is free or not, but what about loading map? Client contains sprites etc., but should they also have map files or server should tell client where is the grass and where is water etc...
How to keep data by server? Players should be represented as files in one folder where server have to find right file, open it, get data and send it back for many players? Maybe database server + database + sql would be better idea?
Any ideas/knowledge about MMORPG structure?
Is Java a good choice for 2D MMORPG?
MMO's are not easy programs to develop. It sometimes takes experienced teams years to develop one, and the questions you ask here don't seem to indicate you are a very experienced programmer. Having said that, I would suggest taking a look here:
http://slick.ninjacave.com/
http://www.13thmonkey.org/~boris/jgame/
These resources might be good starting points and get you up to speed quickly, but I'd suggest looking for a good tutorial on how to sync client/server data, en get a bit up to speed on programming Java in general.
I developed Browsergames in the past. Usually it is a good idea to put "static" data (data that doesn't change very often, like map layouts) into the client, so that you don't need to resend it every time.
I would definitly prefer a database (some sql or nosql) to file-based storage. If you wan't to improve you coding skills and make them more marketable than definitly go for a database.
If you really want to release a simple game, than I would go for html5 as frontend. The graphic capabilities of JAVA a pretty limited. Also nearly nobody would download your game prior to playing it.
Dear Stack Overflow Community,
I am a Java programmer in front of a task of building a complex, data-driven, web application (SaaS) and I'm searching for technologies to use. I have already made some decisions and I believe I'm proficient enough to build the appliaction using just the technologies I have decided for (I'm definitely not saying it would be perfect, just that it would be working). However, I'd like to make my task easier and that's why I need your help.
Brief description of the project
Back-end
The application will be heavily data-driven, meaning that everything will be stored in a self-descripting database. This means the database itself will be entirely described with metadata and the application will not know what data it reads and writes. There won't probably be any regular entities (in terms of JPA #Entity) because the application won't know the structure of the data; it will obtain it from the metadata. Only the metadata will have a pre-determined structure. To put it simply, the metadata is the alpha-omega of the application because it will tell the application WHEN and WHAT to display and HOW to display it.
The application will probably utilize stored procedures to perform some low-level tasks on the data, such as automatical auditing, logging and translating to user's language, thus most likely eliminating any possibility to use ORM frameworks because there won't be just simple CRUD operations. Therefore, JDBC seems like my only option (doesn't it?).
Front-end
The UI will be "dumb" in terms that it will not know what data it is displaying (to some extent, of course). It will just know how to display it based on the metadata which it will obtain from the database. All UI controls (like menu items, buttons, etc) will be created based on current application's state and the UI will NOT know what the controls do. This means that clicking a menu item or a button will just send an identifier of associated action to the back-end and the server will decide what to do.
My goals
My main goal is to have the application as lightweight as possible with as least dependencies as possible. Because the application will be very complex, I'd like to avoid any heavy framework(s) because there is a very high probability that I'd need to customize a lot of its functionality.
What I have already decided for
Please object to the following decisions only if you think they're absolutely non-viable for my application, as I have already implemented some core functionality using these technologies:
Servlets on Tomcat, Guice DI, AOP (AspectJ)
I believe all of these technologies are lightweight enough and I don't need to learn J2EE.
GWT with GIN-jection on the front-end
Seems like the best option for me because I'm very familiar with Java and Swing and don't want to write any Javascript, PHP or learn a new language. GIN is a little brother of Guice and I will be using the same syntax and principles on both the client and server.
MSSQL RDBMS
This is actually a requirement from company management as I'd much rather like to go with an open-source solution. Too bad for me..
Maven 2
I think no-one can object to this :)
What I need help with
DB communication
I think that ORM is ruled out (is it?) so I need to use JDBC. Do you think Spring JDBC is lightweight and flexible enough for my use? I would often need to "blindly" read data from database, mapping it to some generic entity (because I won't assume any pre-determined structure), and then send the data using some generic DTO to the client along with the metadata telling it what data it is and how to display it. Or do you know any alternatives? Or should I do this myself?
Client/Server communication
GWT and its GWT-RPC mechanism seems not very suited for sending the generic data I need. Although I'm convinced that it's doable using GWT-RPC, are there any alternatives? But I definitely want to use GWT.
Security
Do you know any security libraries / frameworks that would help me? I'm aware of the existence of Spring-security; do you think it's flexible enough for my use or I'd be better off implementing that myself? Also, is Spring's IoC an integral part of the Spring framework, or would I be able to continue to use Guice?
Anything else that you think might be useful?
I really appreciate any advice and suggestions because I wouldn't dare to try to make such decisions myself. Please ask me if you need more information.
Thank you in advance!
eQui
I think you are over-engineering the solution. Take a look at
http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx
If everything is driven by the DB, you are going to have immense difficulty making things happen in the UI, and you aren't going to be able to use many of the tools that make UI development easier.
I also suggest you take a look at Spring Roo, if your application is mainly just updating data in a database.
UI framework and implications for client/server communication
You say that any UI action will triger the backend (and potentially the DB). This mean that UI interraction will be somewhat slow anyway, and more than that will require a round trip to the server.
GWT is especially suited to avoid as much as possible round trips to the server and do all UI work on client side. In this model, only information that will transit from client to server is real data, and not UI metadata. GWT will do the job, but you'll be using a somewhat low level tool, needed for advenced optimisation you'll be unable to perform anyway...
Framework like ZK or Vaadin seems more suited to what you want to do. The client side has nice widgets with a rich UI, but you manipulate the UI from the server side. The framework manage client/server communication for you (no need of REST, RPC or javascript). The main limitation of theses framework is scalability, with all theses chatty round trip. But because your requirement impose that chatty behaviour anyway, you could really benefit from the abstraction they provide, are they are at not cost in your case.
I have tried both GWT and Zk to do some proof of concept for my company. We ended choosing GWT, because of it's hability to be embedded nicelly into any existing UI and to fine tune what you do... In particular avoid as much as possible rountrip to server. But ZK is really easier and faster in term of developmeent hours.
The side effect is that would totally solve your client/server communication concern, leting the framework performing it in an optimized way (Zk is able to intelligently regroup several UI event before sending them to server).
DB and ORM
For DB design, i tend to think that using fine granularity things in DB will make it very very slow. If each widget is one or several rows in the database you'll have to perform many lookup to perform the simpliest thing.
Problem is if your UI is just a little complex with a few dozen of elements (a few button, checkboxes, labels and widgets), compositing a screen will require lot of requests to the DB. Rendering just one page might be very slow and scalability would be very very bad.
I know this because i worked on somewhat generic bug tracking system with similar (but simpler) requirements than yours and we had exactly this problem.
So i would try to describe UI in some templating or XML format. Maybe you'll not show this data to the user, providing it with a nice abstraction, but instead of performning many queries for just one screen, you'll save the whole screen as one blob.
A really dumb and basic implementation of this would be to store HTML/CSS/PNG file in your DB and load it as needed, with user being responsible for making theses HTML file by hand. Of course this would be terrible for the user. That's why you need a nice and fancy editor UI editor that would work on an intermediary format of your own. Another dumb implementation would be some sort of wiki templating. This is not what you need, you need more. But you have the idea, I would seek in that direction...
For the maintenance and debugging too, this would be far easier to the whole UI description to a few file, to understand what is really implemented than to read lot of tabuled data in your prefered SQL editor. Users would have they export/import format to easily version, backup or experiment.
Security
I would say by hand... Because you have a generic UI generated by user it seem likely that the security will be generic too and dependant of database content.
Hope it help...
For the backend, i implemented a program which had a similar interaction with the database. the code was database structure oblivious, instead, it read a config file describing the db and could construct complex sql queries based on this information. most of the code is proprietary, but one bit of it got pushed into an open source project called sqlbuilder. may be useful to you on the backend.
I think you're on the right track, with your tool seclection. Your 100% data driven model is going to be hard to maintain. But I understand that's a requirement not an option. Normal source control is going to fail you becuase of the ui application logic all being in the meta-data. You'll need some good test databases and some way to maintain them, such as regularily mysqldump them out and check them in to souce code control to handle all the differences, etc..
You're wise to stay away from various ORM solutions and just use JDBC for this type of app.
Let me give you some warnings about GWT. On the surface it will abstract all the uglyness of html, javascript away and give you clean heirarchy's BUT...
1) If the abstraction fails you how do you easily debug?
2) Do you want any of your site to be visible to Google or other search engines, if yes GWT is not for you
3) Do you want to use any HTML5 technogies or do you want to be stuck in IE 5 compatability mode?
So...
I think you'll be much better off Implementing the UI as simple HTML controls with a small set of jQuery ajax interactions with the server. You can define an input type in your database, your serverlet can generate an input tag and then you have two options you can have some standard event bindings in jquery to tell your server that button1. is clicked, or that select2 has changed, etc.
Your server can send back javascript to change the state of the ui - simply load the javascript inside a div so it runs on the client. or 2) You let the input submit the data to the server and do an old school page refesh and the servlet build the next ui screen based on the database.
Building an interface dynamically in HTML from a database is easy and straight foward compared to doing the same in SWING or Windows Forms. You just have to write out a big text string, been doing that since 1999.
That approach is going to be much more lightweight - simpler to debug, understand and modify in the long run than going with the "GWT automatically compiles to unreadable javascript that doesn't run in my browser for some unknown reason" solution.