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, ...
Related
I'm currently working on a client-server project where the client sends a request to the server and the server runs a database statement based on the information from the client. As there's no static length for the output I add all the data to a ArrayList<String> and send it back to the client.
The data that the client requests has a certain hierarchy so that one could also display it using an XML file (however the output to a GUI is wanted here instead of file creation). There's several ways of displaying I came up with. One would be using a simple text area, however using this, I need to do applying the layout myself and the option of folding where I can expand and collapse certain items is not possible.
Another possibility of course would be using a simple JList, however I read on Stackoverflow that using a JList to display hierarchical things is way easier done using a JTree.
When I decided trying to implement JTree I also found the Genealogy.java file provided by Oracle in their documentation of JTree. As to be seen in the first examples of this documentation there is always a filestructure being displayed and hence also a filestructure kind of representation (using folder- and file-symbols) is shown. In contrast to this Genealogy.java only shows the names of the persons so I tried to adapt the implementation from Genealogy.java to my case however I'm completely clueless of how to do this as I don't even know where these symbols come from and where I could possibly disable them and also don't really get what some of the methods I need to implement do.
As I'm currently really clueless of how to possibly accomplish that I really need some detailed help (only telling me to come up with my own implementation of JTree or TreeNode doesn't really help me at this point). Is there any simpler way or is the need to implement any of the before mentioned interfaces inevitable and if so, how would it be done?
EDIT:
This is how it currently would be displayed (example taken from the Oracle documentation, showing folder- and file-symbols in front of the string):
And this is how I want it to be displayed (also from the documentation, this time only displaying a string as node):
The answer almost certainly will be found via the (icon of the) TreeCellRenderer used for the tree nodes. See the File Browser GUI for tips. It shows how to set the icons in the FileTreeCellRenderer. Admittedly the point here is almost exactly opposite what it was there, but it still comes down to the same thing - the icons.
The section of the tutorial that covers it is How to Use Trees: Customizing a Tree's Display.
I want to have a list of pre-fabricated templates, where each item in the list has a first name, last name, and buttons that relate to that item in the list (Delete, rename, extra info, etc.) what would be the best way to do this?
The closest thing I can think of that would be similar would be something like a twitter feed: http://www.androidguys.com/wp-content/uploads/2013/12/Twitter-Feed.png
Where each "post" is based on a standard template, and database info is plugged into it, as well as buttons that belong to that post.
Currently I have it so my app uses a list of fragments, but that seems really hacked together and takes a lot of time to load more than a few of them.
Is there an alternative? I think I read somewhere of someone recommending another person to create a custom viewadapter, but as I am still somewhat new to android, I'm not sure if this is the best way to do it.
I was working on creating a weather application in Java using Weather Underground and I found that it does have data for some cities.
Initially, I was planning on using GeopIP to get the user's location automatically but since the support for cities is limited I decided to let the user choose the city every time the program starts.
I want the user to be able to choose a city from one that is supported by Weather Underground. The user will enter the name and as he/she enters the name, the possible locations will be displayed in a way similar to the one shown in the picture.
My question is:
How do I implement this search feature ?
My initial guess was to create a Vector containing all the names of the cities and then use brute force to find the match and display in a JPopup or a JWindow containing a JList but I guess there has to be a better method
Rephrase:
What I do not understand is WHAT INFO do I keep in the data structure I must use ? Should I manually create a list of cities that Weather Underground supports or is there another way to do it ?
Take a look at the Trie data structure (also known as digital tree or prefix tree). Autocompletion is one of the most common examples of it's usefulness.
The following article has a nice an very approachable explanation:
Roll your own autocomplete solution using Tries.
if you google autosuggestcombobox you will get some interesting results:
This one is written in JavaFX - I have used and extended it myself already. It is quite useful. What you get "for free" with JavaFX: a context menu with right-mouse click which is auto-generated containing some of the usual "stuff", like cut, copy & paste and even undo! So, I can recommend that solution. To get into JavaFX isn't so hard - and I think it is much easier to learn than Swing - and looks so much cooler! However this implementation has some drawbacks - especially when the layout is not left-aligned, because it is simply a text field on top of a combobox.
OK - but if you want to stick to Swing - you could probably use this one. I haven't used that myself, but the code looks quite straightforward and pretty clean - cleaner than the implementation for JavaFX I must admit (but that had some nice features). So - maybe you try - and extend it? It is built simply on JComboBox.
I'm planing some kind of information app for android and I'm not sure what technical design is best (because this is my first real android app).
The app which observes the latest information from an server consists of 4 screens:
Main screen -> shows the information (consists of a thread which updates the information by server push)
Configuration screen -> you come here from main screen if you'd like
to configure the information type you want to see.
message screen 1 -> you come here from main screen to send new messages to the server. The screen consists of a radiobutton list where you have to specify the type of information you have to send.
message screen 2 -> You come here from message screen 1. Here you can type the messages and send it to the server.
My thought is either using 4 Activities each containing one view or using just one Activity which contains a ViewFlipper of these 4 Views. What is the best approach and why?
Activities have their name for a reason. Each "action/activity" should be placed in a seperate activity. The user want's to configure something? Send him to the preference activity. The user wants to take a picture? Send him to a photo activity. And so on.
Therefore I think you should have 3 activities here when you split this by actions:
Main screen (user activity "read information/messages")
Configuration screen (user activity "change preferences")
Message screen (user activity "send a message")
For the last one you could use a ViewFlipper if you want to split the sending into two different layouts.
What advantages does this have?
Well, first of all you don't have a big ball of code in one activity that handles everything. Certainly that's possible, but can get somewhat ugly. Maintainablility here.
Also remember that we are still in a mobile environment. Yes phones are really powerful these days, but they still have very short run times on battery. So don't waste battery when you don't have to. Which would mean in case of one giant activity that everytime the user wants to send just a message, he has to load all the other stuff with it. Unneccessary code executed -> unneccessary CPU cycles -> battery drained for no reason.
Apart from that it's convinient for you because the framework supports you this way. For example: the backstack handles a lot of stuff for you already, e.g. you don't have to manage all the back-key logic (you would have to keep track of the layout and the back key depencies otherwise).
If you want to make use of androids intent system for 3rd party apps, this is also very useful. You can control access to your activities on a per-type basis. E.g. allow other apps to call your message activity, but not your preference activity. If you have one big activity this becomes difficult, with some intent extra parsing just to determine which screen the other apps intents to display. And that's propably the biggest reason why activities are activities. Apps can work on a action-base with each other.
I'm wandering myself what component is the best for displaying fast search results in swing. I want to create something like this, make a text field where user can enter some text, during his entering I'll improve in back end fast search on database, and I want to show data bellow the text box, and he will be able to browse the results and on pres enter result will be displayed in table. So my question is is there any component which already have this logic for displaying?
Or is it's not, what is the best way to implement that.
This search will be something what ajax gives me on web, same logic same look and feel, if it's possible on desktop application.
Are you looking for something like an AutoComplete component for Java Swing?
SwingX has such a component. See here for the JavaDoc. It has a lot of utility methods to do various things, i.e. auto-completing a text box from the contents of a JList.
I strongly, strongly recommend that you take a look at Glazed Lists - this is one of the finer open source Java libraries out there, and it makes the bulk of what you are asking about super easy.
You will have to first attach a listener to the JTextFields Document to be notified whenever the user types in the field (or changes it).
From there, you can fire off any server-side code you need. The results of that can be used to update a listbox.
A few things to keep in mind:
The code to do the search against the backend must be in another thread
The code that updates the list box should update the list box's model
You will need to manage all your backend search results so that you only update the listbox with the most recent result (e.g. user types 'A', backenf searches for that. Meanwhile, user has typed 'C', kicking off a backend search for 'AC'. You need to ensure the results from the 'A' search dont' make it to the listbox if the 'AC' search results are available).
Use Hibernate Search.
The SwingHack (http://oreilly.com/catalog/9780596009076/) book has an example of this.
In the interest of killing two birds with one stone: have a separate indexing thread. This will:
Improve the speed of searches whenever they are executed.
Improve the responsiveness of the UI since indexing is happening in a separate thread.
Of course, exactly how you perform the indexing will vary widely depending on your particular application. Here is a good place to start researching: Search Indexing. And please, ignore the reference to Web 3.0 [sic].
It is possible of course. It is simple too. For drop down list of terms just use popup menu. This is simple. The background processing of entered text is simple too. Enjoy!