Imagine we have a chat application and conversation page has been opened. If one of messages edited by other user or message's state changed from sent to deliver, Action update Store with new messages metadata. For example,after these actions we have a list of messagesState or messagesText or simply messages with modified data in our Store . So in this scenario we don't know which row has been edited and we render all the data in view again. Is this behavior one of Flux principles? Isn't better to update and send event about updated object only?
( I developing Android application and so I don't use reactJS or other library like this)
Also I going to think it's good if we mix MVP with Flux! because if one view want to change itself we have to put logic in view.for example view directly get store data and check it belongs to which element! I think a presentation layout is good for this type of situation. Has anyone tried this?
So in this scenario we don't know which row has been edited and we render all the data in view again. Is this behavior one of Flux principles?
Yes, it is! One of Flux principles is immutability of data, in order to avoid doing incremental change handling on every object in a parent data structure. This also immediately answers your second question:
Isn't better to update and send event about updated object only?
There are plenty of helper libraries for your Android project out there to establish immutable datastructures. To name just a few:
https://github.com/immutables/immutables
https://github.com/konmik/solid
In comparison, ReactJS is able to only perform updates on the "UI-Layer", the DOM, by comparing the current DOM tree to the to-be-updated DOM tree and therefore can perform incremental updates.
You could mimic such a behaviour in your Android views, by implementing something analog to the shouldComponentUpdate() function of ReactJS for your views.
Related
I'm used to HTML development. Now I'm starting to program my first Android apps. In the tutorials I have read it looks like Android development favors using a new activity for each different form.
Nothing-less I think it's quite possible to use a single activity and use the setVisibility(View.VISIBLE|View.INVISIBLE) to show / hide GUI forms elements (This is much more similar to what I'm used with HTML-AJAX).
Is there something wrong with this way of development in Android?
Using a single activity(process) also allow to use singletons to share state and data between GUI components, while the multi-activity requires a "slightly" complex communication system using extra data to communicate the selected id, ...
I wonder what are the disadvantages of the single Activity "pattern" and why no tutorial/manual on the Internet use this technique to develop Android apps.
Do fragments have any advantage over showing/hiding views when I have no intention/interest to reuse the component?
Approach : Single Activity :
This approach will show/hide UI elements based on user interaction with app. Showing a UI Element draws View hierarchy starting from that element. This is called Layout Pass. This layout passes are expensive operation when performance is calculated. This is not advisable way to implement.
Approach : Single Activity, Multiple Fragment :
This approach will also have Single Activity but multiple Fragments associated with this activity. Each fragment defines new UI screen based on application requirement. More details available : Android Developer Guide : Fragments This is much advisable way to implement your requirement
I think there is nothing wrong, but depending on how complex your app will be, the source code can easily become very confusing!
Do you want those code happen:
elementXScreenA.setVisibility(false);
elementYScreenA.setVisibility(false);
elementZScreenA.setVisibility(false);
elementXScreenB.setVisibility(true);
elementYScreenB.setVisibility(true);
elementZScreenB.setVisibility(true);
And then, maybe after that:
elementXScreenB.setVisibility(false);
elementYScreenB.setVisibility(false);
elementZScreenB.setVisibility(false);
elementXScreenC.setVisibility(true);
elementYScreenC.setVisibility(true);
elementZScreenC.setVisibility(true);
No. I don't want to do that !!!
That just base on your ways for funny. There are many many disadvantages to do that, and I don't think there are any advantages in this approach. I can list some. Any comments will add to this list:
Design UI. How can you code multi layout on one xml layout file? Android Studio doesn't support this. You will see elements overlap elements
Performance. Load all your application UI is not an intelligent way. You lost memory, lost CPU. Although you set invisible, your memory still store those information, and when transition between elements, invisible elements still count into.
Maintainable. I'm working with a medium project, and still headache every day with bigger and bigger fragment and activity. (in case that each layout for each activity/fragment). How does everything become when you make all your layouts into one activity?
Collaboration. All layouts in one file. All your application in one file. How can you can collaborate between members? Code conflict, wrong edit ... Noooo. Stop that :)
No. Stop that. You just make element invisible when that element need this. For example, floating button when user scroll down list, error message textbox when no error need to show, ...
Is there any Listener in Java, which can detect, if the content of the page has been changed? "changed" means text in the page has been added/removed...
Process: Author modifys the page and activate it. In publish Instance it must be checked if the page content has been modified/changed
I don't think there is such listener. You're gonna have to reload/access the page or you can hook it up so when the author submits his changes you insert a value to the database that this specific page has been modified. After that you just read the data from the DB using a timer that triggers every now and then and if new line appears you do your action.
This is more of a design question and you should think about what project you're working on and what's the best approach to implement this feature.
Apache sling can handle events. There is nice tutorial here http://sling.apache.org/documentation/tutorials-how-tos/how-to-manage-events-in-sling.html .
Basically create a listener ad check if the event relates to a page node (or its subnode). Then apply whatever logic you want.
Be careful to check whether you are in an author or publish instance ( or turn off the service in author)
Let's say I have a set of items that I need to display in a table/list. The set is highly mutable, because background-jobs and other users access the same data.
Now the resulting output has to contain links that trigger actions on the underlying data. These actions might remove an item from the set, but don't always do so.
Since the model of a ListView (I'm not quite sure about DataView right now) is index-based, it's bound to fail in such situations. I get errors when I click a link that refers to the wrong object because the order or size of the underlying list has changed.
So what I need are links that always refer to the natural ID of the object they are supposed to operate on. When a link gets rendered to the user, I want that rendered link to always refer to the same object, no matter what happens to the set that was used at render time.
The easiest solution that comes to mind is using a stateless link only containing the action and the id, leading the user to another page. But this has the obvious disadvantage that I loose all the benefits the Component-system provides in the first place.
How would you solve this problem?
DataView is non-index based, see IDataProvider#model(), so you where pretty close to the right answer.
I have something of an abstract question regarding managing live feeds/polling on web sites.
I am creating a web app (built on Java/Spring/Hibernate) and on the user's home page I want a live feed of the latest activity from all the members of there team, and I am trying to work out the best way to handle this query on the server side.
The brute force way would be to load the current users list of team mates, and then iterate through each of his team mates, loading their latest conversations/file uploads/etc, and then merging all this activity in to a single list sorted by timestamp and returning that (lets say for sake of example that we just return the top 10 latest activity for the feed).
However, that seems very un-performant, especially as this operation would need to be done regularly (depending on the polling interval).
I have also considered making all the potential activities (conversations/status updates/uploads) as extending an Activity class and then just having a direct SQL/JPQL query in a DAO that selects all the latest activity from a set of users to be returned, but concerned that might bypass the caching and continued access to the DB would also reduce performance.
Has anyone handled this type of problem before? any one know what a good approach is?
Thanks!
This is an old one now, but here is what i did for this:
All tasks that should appear on a live wall extend Activity (this was already the case)
Created a new Notification object, the Notification had a link to the underlying Activity and a link to a user (who was being notified).
Created a pre-persist hook for Activity that created a Notification object for the Activity being persisted - it did this for every user that was interested (all users following the user that was persisting the Activity)
For the moment, Notifications are persisted/retrieved to the DB - possibly not scalable to very high volumes, but the approach I think supports moving to a Queue based system (such as LinkedIn's Kafka queue library which is designed exactly for this purpose). As it is per-user, it also provides the option to have a read/unread notification flag for significant notifications.
I am a new to programming with Java and I would like to know if there is some common practice for managing state of opened document (is current state saved or dirty) , saving document, opening, creating new document and so on. How do you approach this?
Right now I have my little Swing application and have actions for opening and closing document and creating new one, but I don't know how to manage if user has saved file or not (I need this to check if user wants to create new one or open existing while working on current.)
Is there some pattern for this? All advices are very welcome since I am still learning how to swim with Java.
As far as I know Swing does not have mechanisms for managing document state. You have to do that yourself. But then, it is not that much code that has to be written and if you have several different documents in your app you can put that stuff in an abstract base class.
The basic approach has been outlined already: just have a "dirty" flag in your document data structure. You should put some thought into writing down which of your operations like "create", "open", "save", "close" should modify and evaluate this flag. I would suggest a state chart (not necessarily the UML state machine variant) as a tool to specify this.
If you need more complex functionality, especially undo/redo, take a look at the Memento pattern. Most of the code that has to be written when you use this pattern is specific to the application and its data structures (i.e. the types you create for managing documents) so it would be hard to impossible to effectively generalize this and put it into a framework like Swing or RCP.
You have a boolean variable named isDirty which starts at false.
Every time a change is made to the document it is set to true by the code.
All other program functions (Open,save,new menus e.t.c) check the status of this boolean
before doing anything else.
This way they also present the familiar dialogs: Are you sure you want to exit, Discard
your changes e.t.c
I have used this several times on real world Swing Apps
You may think about working with temporary versions of your document (i.e. you open main document, but when you edit it then temp document is created). In this case another user who opens the same document will see original doc. As I know it's common practice..
But I'm not sure that you want to maintain so complex behavior..