This is enterprise android app, We have many applications in pipeline and we don't want to repeat some horizontal concerns like communicating to our backend servers, securing the data, single sign-on, sending current state of app etc.
We are thinking if we can develop an app which takes care of all these cross cutting concerns and other apps only utilize the services provided by these apps. Is this feasible ? Is this design ok or there should be other approach to solve this problem.
Just pointers can be enough :) I can figure out the details.
Is this feasible ?
It is technically possible. However:
When the user uninstalls this magic app, all the other apps break
Securing the IPC to the magic app is doable (use signature-level permissions) but important
Usually, you don't create an app to address "horizontal concerns" -- you create a library. This is true for most operating systems and development frameworks that I have ever encountered, anyway. In Android's case, that would either be a JAR (if it is pure code) or an Android library project (if it needs resources).
Related
If I need to design an entire android app and host my app on google play, and my users need to get real-time data, how would I go about designing the backend.
I learnt few things about views, view groups, layouts, event listeners in java, programming in latest android studio. But I'm just in the learning phase.
Is there any other better IDE. Can we program in atom, does it has any package that can emulate android phones.
Mainly I'm concerned about the DB choice, frontend-backend communication. Is there any service which is open source for hosting in the cloud that has a great uptime and supporting easy scaling. Of course, I can google each and everything, but those will be on different perspectives. I just wanted some answer which is tailor made and easy to understand.
This question could definitely result in a myriad of answers and approaches. But, in terms of something straightforward to maintain (considering you have Go tagged in the question) I would recommend checking out the following:
For using Go, I have found Echo to be a pretty awesome framework to bootstrap Go web services. It offers a very flexible and performant router that uses a middleware design pattern, as well as a lot of other nice features.
For hosting and maintaining your web services, you should look into using Heroku. They have a pretty amazing platform that officially supports Go deployments. You can start for free, and then scale up your services pretty effortlessly. They also offer myriad of third party integrations for monitoring, logging, emails, sms, and databases.
In terms of databases, that one can't be answered really without a significant amount of knowledge around what you are doing with your data - but using Heroku, you can spin up a PostGres SQL instance, MongoDB, and Redis for free. For what you are doing it sounds like a combination of the above might be useful for your needs.
In terms of Android development - I have not found anything better than Android Studio. It's free, provides all the emulators you could ever need, and in general all the features you would want out of an IDE to do Android right, plus it is maintained by Google.
Good luck!
I am looking to make a small web application for my group. The issue is the IT team makes having a server etc... impossible. The application would be a custom searchable database web-app. I am restricted to just having a folder on a network drive. I cannot have any installation on the users' machines. I was reading that web-apps might work. I could have all the information on the network drive everyone has access to and users can just type the address in their browser and fire up the web-app. I came across stripes and I am wondering if it fits the bill. There cannot be any footprint other than files in a folder. And many users need to access the files also. I also want it not to require much beyond a Windows OS. Will this work? The application is not really complicated. IT is not helping me but would be a great time saver for the group.
Thanks in advance.
Stripes is a really good, lightweight Java web application framework.
However, it won't work without a sever. So, to answer your question, the simple answer is: no.
Your requirements are absolutely not a recommended scenario, especially in a corporate environment. I'd always opt for a simple DB-based solution.
You could, however, and if your corporate data security guidelines permit it, use a (free) Google App Engine account, to run your Stripes application. Of course, any other free or cheap platform will do.
If you can only have a folder with files in it then no, you can't use Stripes. In fact, you can't use any web framework because web frameworks dynamically react to input. Just having a folder with files in it won't let you dynamically react to input. You need a server running that can interpret requests.
I´m soon to start a new mobile app project and I dont have that much experience with either iOS or Android development but I have used Vaadin for presentation tier on different occasions.
The app will most likely be lightweight for the mobile client but more heavy for backend servers(jboss). I feel kinda lost so i´m asking you.
Question: What are the drawbacks of using Vaadin touchkit compared to other frameworks/ build from scratch? Where might a problem occur? Any input and recommendations are welcome!
I am currently developing a small application using Vaadin TouchKit that once it enters production will have some hundreds of users. I haven't been able to locate any publicly available apps in production that have been implemented using Vaadin Touchkit, so what I'm going to list here is based solely on my personal experience with the technology.
Drawbacks compared to native applications:
I'm assuming this is what you refer by "building from scratch".
As this is web techonology, your application performance will always correlate heavily with the quality of the users Internet connection. If you have to render large UI's with a lot of components and details, it will be slower than doing so in a native application. A lot slower if the users connection is poor. Or if a connection is unavailable, then your application pretty much becomes unavailable. There is a way to use HTML5-cache for providing an offline-mode in a Vaadin Touchkit app, but it is not very useful for storing large datasets as the cache has a lot more limitations than for example an Android SQLite database. For simple UI-stuff it might be viable, but storing data for offline-access is in my opinion pretty much out of the question.
Other than the above mentioned points, I have not run into any missing capability, as you can use any Java library at any time on the server-side, and your application will be running safely in a servlet container.
Upsides compared to native applications:
You didn't spesifically ask for the upsides, but I guess this is any input and recommendations.
Your Vaadin Touchkit app can run on basically any mid-high tier mobile device launched after 2010, basically excluding only the ones with Windows Phone OS, since Internet Explorer does not use WebKit for rendering and other browsers are not available as far as I know. And since this is a web application, it does not exclude any other desktop browsers than Internet Explorer. By creating one application, you support roughly 80-95% of your users.
As mentioned, any Java library, any internal API, any authentication method supported by your hosting environment is available to your app, which is not as easy to implement for native mobile applications. This can be overcome with great software engineering, but demands a significantly higher amount of developer resources, not to mention that you are still stuck doing it for each platform separately.
And of course maintenance of a servlet app compared to the maintenance of a native application is considerably more simple: deploy once, all users get the changes without doing anything. No app store, no versioning, no hassle.
Vaadin TouchKit compared to other web development:
I am not familiar, at all, with web application development without using Vaadin, so I am not going to tell you whether or not it is the way to go compared to other modern web application technologies and frameworks. All I'll say is that in my experience Vaadin makes creating UI's and backend functionality relevantly easy and more graspable if you are familiar with Java development and desktop application development in general.
To conclude, don't rush in to create your mission critical application using Vaadin TouchKit before at least prototyping with it, and getting to know the performance and limitations it presents. For certain type of applications, it might be one of the best solutions. For a certain, larger group than the other, it is probably one of the worst. It is not a very mature or generally adopted framework, but it is useful. I'll be happy to hear more about the type of app you're planning and help you figure out if there are any showstoppers for using Vaadin TouchKit.
P.S. You've probably already run into this, but this document opens up the guts of one of the TouchKit demo apps:
http://demo.vaadin.com/vornitologist/VAADIN/tutorial/touchkit-tutorial.html
I just tried out vaadin touchkit examples on my android phones, well now I got affirmation why I prefer native software over html in some cases. Try it out - dont be confused by nice-looking styles, just try to USE it, this is what apps are made for. In my case I cannot withstand non responsive GUI or not smoothly scrolling lists. Again, for a simple gallery - a JavaScript/HTML solution is just perfect :) So the right way is the hybrid way! (imho)
Vaadin Touchkit offers very good user experience and provides wide range of UI components to apps.
Its default iOS theme provide almost iOS like UI and it also offers many other themes too.
But this will not run as smooth as platform specific mobile apps. as ultimately it will not completely leverage the real power of mobile platform features as finally it is going to run in a mobile web browser. as compared to native mobile apps
Find more detail on vaadin touchkit and comparison with similar technogies like ZK Mobile and native platform specific apps. : http://jtechnoprojects.blogspot.in/2012/12/vaadin-touchkit-vs-zk-mobile-vs.html
I just started working on a project which will about making a big website.
With big i mean:
Webshop
Forum
Normal Website (Information pages etc..)
At first i just wanted to pick a decent open-source webshop and just built my site around it.
But then i started thinking about how to expand etc.
I started to think how i would like this website to be acces from a mobile phone. Not just with a browser but with an App. (I have decent experience in making apps for Android & Iphone). So the real question is:
Would it be smart to make the "Core" of my whole website in Java and use services to acces it and thus allowing different frontends to use the same "Core". Like:
- PHP for browser frontend
- Java (android) for the android App
- Objective C for the IPhone App.
And let them all just communication to the "Core" through REST (Json).
What will be the advantages / disadvantages with this approach and will there be a significant delay in rendering eg. a webpage (http request to php, then php making calls to java server (different physical server) then accessing the database and then returning it all, so php can format it to HTML).
Hope hearing some answers or suggestions!
I would skip the Java layer and make the "core" PHP. There is a wealth of tools and frameworks (like Zend FW) for building thoses components in PHP. Design your application around a REST interface and allow your mobile apps to use REST.
Better yet, use Rails. It's so easy to design and set up a REST interface.
I think your solution is “smart”. The only changes I suggest are:
Use the same platform to build both the "core" and the "browser frontend." This way you will have more productivity.
Keep the "core" and "browser" frontend on the same server, if possible in the same process. Unless you have a reason do it differently. This will reduce problems with performance, latency and so on.
If you're already familiar with Java I would suggest you look at something like GWT (or GWT + third-party libraries like Ext GWT or Smart GWT) for your front-end. I don't see the point in picking another language for the front-end unless you really want to learn something else (e.g. PHP as you suggest in your question).
I think the rest of your approach is sound (i.e. Java on the backend, providing RESTful services, etc.)
I'm currently in the research phase of my dissertation project.
My project is a ticket booking system for a mobile device and I have chosen to target Android.
I anticipate the need for a client/server architecture with a central server, and so am currently looking at how Android could communicate with such a server. The server would grant the client access to ticketing information, and the client would send information about ticket bookings to the server. I'm looking at Java EE for the server as Java is the language I'm most experienced with.
I'm aware that Android comes with java.nio and java.net, as well as some org.apache packages, but am also looking for libraries/technologies that would be possible to use with Android.
So far I've not found anything massively helpful on the internet, so I'm seeing what SO can suggest.
Specifically I am interested in knowing:
What support is there for various middleware technologies in Android? e.g.
RPC based middleware
CORBA
Message based middleware
Web services such as XML-RPC, SOAP, REST
How well (or not) do existing Java libraries work when used on the Android platform? (e.g. If I wanted to use a library/API designed for Java SE rather than Android what problems might I encounter?)
Ideally, as the focus of my project isn't meant to be the communication between the server and client, I could use an existing middleware to handle the communication, but I am prepared for the worst case, which is having to write my own.
What support is there for various
middleware technologies in Android?
My personal opinion -- though I do not feel I am alone in thinking this way -- is that only protocols specifically designed to run over the Internet are remotely suitable for use with a mobile client. So, of your list, the only one that I would even entertain would be:
Web services such as XML-RPC, SOAP, REST
Some people have been maintaining an Android port of kSOAP2. However, I get the distinct impression that most Android developers working in this area have tended towards REST and REST-ish protocols. If nothing else, that's what all the fun Web sites and services are using for an API, particularly compared with XML-RPC (old) and SOAP (old and icky).
I have successfully used both the java.net.URLConnection and Apache HTTPClient libraries in Android for communicating with REST-style endpoints -- both directly and through third-party JARs -- with no real Android-specific issues.
How well (or not) do existing Java
libraries work when used on the
Android platform?
It is difficult to answer that in the abstract. Android implements a substantial subset of JavaSE, but not all of JavaSE, so there's a chance that any given JAR will expect something Android does not offer. Similarly, Android does not use environment variables, command-line switches, or a variety of other things that developers focused on the desktop might have introduced as semi-requirements. So, some things have worked for me with nothing more than a recompile (Beanshell), and some things have worked for me after removing redundant classs (JTwitter), and some things looked like they were going to be ghastly to get working (JavaMail).