I'm a Java webapp developer who is new to Android development. In general, my web apps have a DB layer, a POJO layer, a UI layer, and a BusinessProcess layer. In my research of Android applications, I have not come across the BusinessProcess layer. I have implemented my app with one, but I find it clunky, having to pass in either the DB object or the ApplicationContext in order to access the DB but there are times when I find that I have redundant code. I'd rather have an extra layer handle the logic than copy-and-paste it three times in an Activity. In general, what do other people do? What do you recommend?
A service http://developer.android.com/guide/components/services.html such as IntentService http://developer.android.com/reference/android/app/IntentService.html would act as your business process layer, yet most mobile applications are not generally thick clients but thin clients than user a remote web server as the content and business process authority, at which point the service (or sometimes ContentProvider http://developer.android.com/guide/topics/providers/content-providers.html) would interact with the remote server and cache results in a database.
See http://mobile.tutsplus.com/tutorials/android/android-fundamentals-intentservice-basics/
Edit: A bound service would suit your purposes well, depending if you need the work done synchronously instead of asynchronously.
Related
Ive been understanding Microservices and Monolithic arch type
Within a Mono App, Everything from UI (view) from models to controllers and Services are within that one War file or if using springboot embedded tomcat then its within that fat jar file. ETC
So when it comes down to microservices, do i keep all the UI files within the main app? So like my main app would only contain the VIew Model and Controller (MVC) etc. Do I just use controllers and models to update UI(view) from the data ive gotten from per service?
or do i need to create a presentaional layer (GUi) within each service i create to return that page? what im saying is within the micro do i need to make a view(GUI) within that app itself instead of the main application.
Im still understanding, So lets say our main app runs on port 80 is that where all GUi's(views) and our Models and Controllers will live? then another port will have the per service and i just make that call to just get the data to display it within our main app UI (View).
Im just trying to wrap my head around how the UI works with mircoserives thats the only thing stopping me,
my main point is that. In a Micro app. Ill have Everything from MVC to within one app which is our main app will deploy then within that main app will make API request to the micro service then update the view with our data.
Help me understand this one someone please help me clarify this blockage about how do i implement our UI within a micro arch type. I know this question is all over the place but i was trying to paint a picture.
It depends on your architecture, but in most common cases the architect is as follows:
Imagine you have a shop and in your shop you have Order service on port 8081 and inventory service on port 8082 and so on. each service exposes some rest Api's. Then you will have a discovery server, which brings all of these Rest Api's to a single address together(Eureka for instance).
Then you have a single GUI that consume these API's. These days normally you use React or Vue or Angular as Single page application to make the consumer GUI for your app. In production you will deploy each part on different Docker Containers and config the orchestration with some tool like kubernetis. In this case they will be able to speak together.
In between services sometimes we use KAFKA or rabbit MQ for decoupling the services.
Also, you can implement the authentication by using some services like keycloack which is a complete open source third party to handle both authentication and authorization.
Hopefully this can answer your question.
I have an application implemented in JavaFX and it will be migrated to the web platform, but it will take some time for that.
Meanwhile, I am struggling with some problems regarding its uses. Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database.
My doubt is whether running the jar from the allowed network drive will solve this problem. In addition, can JNLP be a solution for this ?
I'd appreciate any help about this.
Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database. My doubt is whether running the jar from the allowed network drive will solve this problem.
It won't work directly.
JavaFX is a client technology, it runs on a client PC. If the client PC does not have direct access to a database, then neither does a JavaFX application running on that client PC.
In addition, can JNLP be a solution for this ?
No, not for direct access to the database from the client if this isn't permitted in your network architecture, you would need a middle tier in addition to the JNLP based client to accomplish this.
Discussion of some solutions to this problem
Typically, the architecture of what you are describing would be built as a multi-tier app.
A client tier, which is the the JavaFX application or HTML javascript application running on a client machine.
An application server tier which handles server logic.
A database tier which hosts the DBMS.
There is a reasonable high level overview of such an architecture here.
Often, nowadays, the application server will serve REST APIs of JSON data, which a HTML based JavaScript web application can easily consume. Such APIs are also easily consumed using JavaFX applications which embed a REST client. An application server services the REST APIs and communicates with a database over JPA or JDBC as appropriate. However, than are many alternate technologies for client/server communication, and you can choose whatever you feel is a good fit for your application, development style and organization.
Spring product specific discussion
As you state your preference to use Spring, consider a JavaFX SpringBoot application.
Spring also includes a technology called spring remoting for facilitating client/server access. Spring remoting provides for multiple communication technologies. I'd advise sticking to the straight HTTP REST based technologies rather than other techniques such as RMI or AMQP as a HTTP REST based back-end can also serve as the backend for a standard HTML/JavaScript webapp which you also mention may be an eventual target client for your application.
If using Spring on client and server, checkout Spring's AsyncRestTemplate, and invoke JavaFX's Platform.runLater API inside the success and failure callbacks of the rest template. Or, use a Spring RestTemplate and control calls to the server via JavaFX concurrency mechanisms. Not sure which would be best for you, possibly the standard RestTemplate wrapped in a JavaFX Task.
Doing this in the correct manner will allow your application UI to remain responsive while it performs network activity (not block the UI thread) and also ensure that you don't violate JavaFX thread rules (don't access controls or modify data bound to JavaFX scene controls off of the JavaFX application thread).
we are developing more java applications. Very simple descriptions.
frontend applications - web app, interact with users
middleware app - provide some functionality for frontend app
transport app - app which communicates with external systems.
These applications communicate with each other through xml transport over http.
Scenario from real life looks like, user create some action in frontend app, frontend app calls
middleware app, and usually middleware app calls transport app (which usually calls some other external system).
Also frontend app could call directly transport app, it depends on flow and business logic etc.
Like you see there are plenty of http calls, frontend app create http call and call middleware app and, middleware app create
http call and call transport app, transport asks some other system and send response back to middleware etc.
My question is. Is this really good architecture? Looks like too much overhead to me. There should be some other better solution,
how to transport data between apps, even they are running in one server.
Data are in 99% simple xml's, created through xstream.
Could be JMS appropriate solution for that?
Thank you
I agree with you that although it will most certainly work OK, the approach with http calls between layers is probably a bit heavy-handed.
JMS would be a very good match if the calls between the different layers are asynchronous and essentially fire and forget (you fire a message and aren't immediately interested in the outcome of the work the destination has to do when it receives your message). Although there are people who do request-reply with JMS I don't feel it's the most natural and elegant usage of a message oriented system.
If what you're doing is synchronous (you call a backend and wait for it to respond to your request) I'd go with normal (stateless) session beans, the creation and management of those has been simplified a lot in EE6.
Another advantage with EJB's is that you don't incur the overhead of the different XML serializations and deserializations that are needed in the scenario you describe.
I am learning to program Java. My objective is to create client server application based on Java and MySQL.
That would have following.
Server Application where all admin controls would be available to configure.
server application will be the only to have access rights to MySQL.
Server will have all functions and objects that clients will require and call and get that functionality. (Reason for that is "I don't want to share MySQL credentials to client apps or rather i don't want MySQL credentials to be transmitted on the network to clients"). As it would increase maintenance tough and it could be a security loop hole.
An analogy of functionality could be: client calls to server telling to add an Order such addOrder(order_id, payment,..,...,..) and so on.
What are the method in practice for such kind of application these days? A example code/or material to get in right direction would suffice
These days the universal way to expose a service remotely is via a web service. This solution was preferred by the industry over time due to its simplicity and ease of integration to the point that binary based protocols like CORBA are now seldom used.
Take the example of Android applications, they are native application mostly using REST web services.
A REST web service can be easilly integrated in the same way with a desktop application, a mobile application or a web application, even if the clients are written in different native platforms and languages.
As sample code, have a look at tutorials on the Spring stack. For the server see this tutorial for building an hello word REST web service. For the client, consider the REST template.
For security, see this Spring security hello world example. Using the Spring stack in Java will likelly give you the largest number of tutorials and online support.
This sounds like a good place to use RMI, which Java has built in support for. RMI will allow your client to call server-side methods on a local object that corresponds to the server, where all messages/commands get transparently sent to the actual server, where you have your DB access stuff and logic.
We have come across two apps made on google app engine (java) and we need to establish a secure communication between then. Basically we have:
APP1: "Public" APP that provides data in JSON format based on requests in JSON format. The data is private, subject just to the specific request.
APP2: "Internal/Not public" APP that request data to APP1 in JSON format and needs to receive response in JSON format.
The scenario above is working fine, we have both apps communicating between each other. However, we need this communication to be secure and we need to identify (authorization and authentication process) that is really the APP2 that is requesting data to the APP1.
We have thought of many approaches but we haven't come across a final solution, I was hoping someone has implemented something similar.
1) We thought about using oAuth, building a "Provider APP" and making APP2 subscribing to our APP1 through this provider. The reason for us to have look at this solution, it's that maybe in future we will allow a third party app (APP3) to consume the data from APP1 in a subscription mode.
Regards.
Requests from one app to another will always have the X-AppEngine-Inbound-AppId header set to the AppID of the originating app. This header can't be forged by other apps or external services - it's sanitized by the App Engine system.
As an editorial note, though, it's rarely a good idea to separate your app into two separate apps like this unless you really do have an API that could be used equally well by external services. Organizing your app's responsibilities internally is generally much more efficient and just as effective at separating concerns.
This functionality is now built into the App Engine API. Apps can securely assert their identity to other apps.
ref:
http://code.google.com/appengine/docs/java/appidentity/overview.html#Asserting_Identity_to_Other_Systems