Win a copy of Head First Android this week in the Android forum!

Jason Brent Morris

author
+ Follow
since Mar 29, 2011
Jason Brent likes ...
Android Google Web Toolkit Java
South Africa
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jason Brent Morris

Aha, Sorry I didn't realise you were talking about App Widgets (when someone says "widget" to me I think of classes in the "android.widget" package). The official documentation is again probably the best place to look: https://developer.android.com/guide/topics/appwidgets/index.html#implementing_collections

They implement the example with a StackView, but the same concept will apply to a ListView. The WeatherListWidget example uses a ListView in an App Widget: https://android.googlesource.com/platform/development/+/master/samples/WeatherListWidget
4 years ago
Aha, sorry about that. So your question is: how do you put a ListView into a Button or another non-layout widget?

Short answer: you don't

Long answer: you don't, but you can make a ViewGroup (like a FrameLayout or LinearLayout) look like a Button by changing it's style.



Then simply hook an OnClickListener onto the ListView and you're sorted. I would just like to add: before doing something like this, think very very carefully about why you're doing it. Does it make your user interface more intuitive to your users?

If you're not worried about the styling though, you can set an OnClickListener on just about any Android View and it'll work fine.
4 years ago
Hi Andy,

A ListView in Android backs onto an Adapter. If you're familiar with Swing, it's a mix of a ListModel and ListCellRenderer. Android provides some default Adapater implementations for you, check out ArrayAdapter for simple static lists, and CursorAdapter for ones that back onto a database.

If you have a static list of options you can link them as resources in your layout XML file, like this:

Then create a values resource named "arrays" (so the file will be in res/values/arrays.xml), and write the options array into it like this:

That will create a really simple ListView, each item will be rendered as a "simple list item" which corresponds to a standard Android layout resource.

For more info about how to build ListView's and other Adapter backed classes, check out the official docs about Building Layouts with Adapters: https://developer.android.com/guide/topics/ui/declaring-layout.html#AdapterViews
4 years ago
Congrats to the winners, enjoy the book!
10 years ago
Hi Rupert,

I sent a proposal for the idea to the publisher and they accepted (although the final book doesn't quite follow the same lines as the proposal). I found that it's not so much knowing the right people, but knowing the right content and having an idea of how you want to present it.

Most technical publishing houses are always on the lookout for ideas, if you have one that fits with the sort of books they publish they're almost always willing to talk. Most have an email address or a web form where you can submit your proposal, making it very easy to get the ball rolling. Once it's rolling though: it's hard-work, but (like writing good software): it's also a lot of fun.

Regards,
Jason
10 years ago
Hi Johan,

I've played a little with AppInventor, and it reminds me in some ways of a very early implementation of JavaStudio (long before Netbeans came along). I found it to be a fun tool to play with, but as an experienced developer found it a bit frustrating in it's limitations. As with JavaStudio I think it's a great tool to show off to non-developers, or possibly to mock-up concepts but in my opinion you wouldn't want to try use it for a serious project.

The concept and implementation are both good, but I can't help feeling constrained. For this reason I'm not sure what sort of a future it might have, I don't see it being marketed by Google very hard. If the past non-developer IDEs are anything to go by it will either quietly vanish or alternatively turn into a more serious developer-focused tool. That said: I may well be wrong about this, and soon we'll all be out of a job

Regards,
Jason
10 years ago
Hi Robert,

The book is focused on helping new Android developers get-to-grips with good user interface design within the confines of the Android platform. While there is a fair amount of "good design" practiced in the book, it's always related to some part of the Android platform. For example: the chapter on animation details where you want animations, timing, and how it relates to user experience. That said: the example is entirely specific to how Android builds and renders animations.

So while you might well get some useful generic design tricks and information out of it, you'll also be reading a lot that has nothing to do with your target platform.

Thanks for the question.
//Jason
10 years ago
Hi there Maneesh,

In Android XML based layouts are loaded through a mechanism that could be seen as similar to a java.util.ResourceBundle. The main difference is that in Android the resource loader takes far more than just language into account. Some of the additional parameters that the resource loader takes into account are: time of day, screen size, pixel density, and device orientation. The full list of these attributes is available in the Android Documentation.

For GWT I've found that the XML layout structure makes it easier to work with designers that think and work in HTML, while not sacrificing any of that GWT goodness. That said: I don't see the GWT UIBinder adding as much value to my work as the Android loading mechanism.

In neither of these platforms are you forced to work with the XML layout, but certainly with Android I strongly recommend it. Coding different screens in Java for all the possible device permutations would be a nightmare, take significantly longer, and would also require special handling of changes to the device configuration (language, orientation, etc.).

Regards,
Jason
10 years ago
Hi again Johan,

When I say developing layouts by hand, I mean with XML and Java. Some layouts are more rigid and can be built with just XML, but there are times when you need some Java code. I try to shy away from pure Java code when it comes to Android layouts, opting to load bits of the layout with a LayoutInflator instead and then injecting data as required.

This offers the best of both worlds: you're able to build more complex layouts than you can with just XML, but also don't loose any of the great resource loading magic that Android provides.

Cyas,
Jason
10 years ago
Hi Johan,

This is very much a personal opinion, but I generally prefer to write user interface layouts by hand.

In Android in particular, I find that developing layouts by hand encourages you to reuse of layout elements. Reusing layout elements improves consistency, which in-turn improves user experience. It also makes maintaining your application much easier. Using the <include> tag in your layout resources gives you significantly more flexibility with the resource loader, since each included layout file is selected separately to the layout file including it. Visual Layout tools tend to make these interactions, and interactions between your layout XML and source code rather difficult. I've found that writing the code by hand lets you mix-and-match XML layouts and widgets created in Java code more easily, something I discuss at more length in the book. With the number of screens you're suggesting (40 odd) there should be a fair amount of commonality, and therefore plenty of opportunity to reuse parts of the layout XML.

As you say: getting a user interface right takes time, but I find it's always something that takes time. I personally enjoy sketching user interfaces out on paper a few times before actually getting to work on them. Paper and pencil serves two purposes for me: it helps me organize my thoughts and ideas on the user interface away from the constraints of the platform I'll be implementing on (in much the same way as many web designers will do much of their work in Photoshop instead of an HTML tool). Secondly: I find it much easier to then figure out what widgets and layouts will be needed, generally by drawing boxes around sections of the layout.

On the ADT plugin specifically: I don't know the ADT team personally, nor where they plan on taking the project.

Cyas,
Jason
10 years ago
Hi there Henry,

I wouldn't say that Android UI development is easier or harder than any other type of UI development, it's just different. It doesn't have much in common with the Swing API, but in some ways can be seen to share more with the Google Web Toolkit (although even this comparison is not very good).

Android is expected to run on a wide range of devices with limited functionality, and so the same user interface layout won't look great across all of the device variations. Android solves this problem by encouraging (though not forcing) you to declare the layout and styles of your user interface in an XML file which is processed when your application is packaged (a normal part of your Android build process). When you ask it to load the "main" screen layout, the resource loading API will find the XML file that best matches the current device configuration.

As a common example, you want a screen to appear one way when the device is held in a portrait orientation, and a different layout if it's held in a landscape orientation. If this screen layout is named "edit" you would have a resource directory with the following entries:

/res/layout/edit.xml
/res/layout-land/edit.xml

It's a very simple mechanism, and works for many other types of resources (text, images, etc.). More information about how resources are loaded and handled can be found in the official Android documentation.

Finally: your question about what prior knowledge the book assumes. The book is a beginners guide, and so tries to assume as little prior knowledge as possible. The only thing the book expects of the reader is a reasonable grasp of the Java language.

Thanks for the question.
10 years ago
Hi there Johan,

This is a really interesting question, and it's gonna have a bit of a long answer

First off: congrats for even taking multiple screen resolutions into account, theres nothing more frustrating than having the bottom half of a menu chopped off because your phones screen is tiny!

The resource selection is an awesomely powerful tool in Android, but also relies on the fact that all of the resource data is packaged with the application so that they can be selected at runtime. Files in the "res" directory receive special treatment from the packaging tool, so your images will automatically be compressed down (if they can be), see the Android docs here for more info. Any references from XML resources (@drawable/myimage) such as layouts or styles will also be resolved (or at least tested) during this process, so if a referenced image doesn't exist the packaging tool will fail with an error.

As you suggested: one solution is to put all the images in bundles online and download them when the application first starts. This is a great idea, but unfortunately has several drawbacks. Firstly you won't be able to reference your images from layout or style resources. Second, you'll need to figure out which images to use by yourself. This second issue isn't a problem as long as you don't have images dependent on configuration that can change (day / night, device orientation, etc.). Finally: you're then expecting your users to wait through a second "installation" while the images download, unless this happens very quickly it will lead to many frustrated users (especially if the download breaks due to bad cell-tower coverage or similar issues).

You could also use the Android API to automatically scale or adjust some of the images the first time the application is started, and store the resulting image on the device. However: you'll still loose the ability to reference the images as resources, since you can't write the images back into your "res" directory. A trick with this option would be to use string resources to determine how the images should be scaled.

Summary answer: I would say package all of the required images in the "res" directory. Not using the resource API in Android will make your development much more difficult. If you allow users to install the application onto their SD cards, it will help solve part of the problem (I find on-device memory to be a more limiting factor than download size, and I live in Africa ).

If the download does become what you consider to be over-sized, then consider re-scaling the images or downloading those that are more size-sensitive during the first run.

Hope this helps a bit!
Jason.
10 years ago

Cathy Chlevner wrote:Is any special knowledge in design/drawing required to be able to create good looking Android apps?



Hi Cathy!

Knowing something about good user-interface design does go a long way to keeping your users happy. In much the same vein: knowing how to use a graphics package (Photoshop or Gimp) allows you to make better use of the default Android user-interface widgets by creating custom styles. There are many design mistakes that are made by many (though definitely not all) Android developers. I've seen far to many Android applications that are great ideas, with absolutely terrible user-interfaces.

The approach taken in the book is to introduce the Android stack to someone who is unfamiliar (or somewhat unfamiliar) with it, and emphasize the best way to use each part of the API to make your application more natural for your users.

Cathy Chlevner wrote:Does the book teach usability GUI design techniques?



Although the book is a beginners guide, it has a strong emphasis on good UI design. Not just in terms of screen-layout, but also how users expect an application to work. I've related good application, and screen design directly to the features of the Android platform, which keeps the book practical rather than just being filled with long-winded theory.
10 years ago