So I'm on my first android project and I'm implementing a native app. One of the components is to book a seat on a seating map.
General specifications:
Handle venues that have different seating layouts and amount of seats, over 200
The seats can have different sizes and shapes, i.e. large round VIP seats and standard square seats. Imagine small round stadium with a lot of custom seating and different orientation, with a stage in the middle. (I have an image but can't post because I don't have enough reputation)
What I have tried so far:
Created custom seat class with size, seat number, orientation and seat type
Used a StaggeredGridLayout and a view-adapter to load each of these objects dynamically from a DB onto this layout.
My concerns: No matter how much I was worked on it, it never came out the way I wanted. Basically, I think this is better for grid maps with one sized objects like bus seats placed in the distance between each other and doesn't have a huge irrelevant object in the middle like a stage.
I was thinking about changing directions completely after doing some research: Using webview? Each venue would be a web page, that would be linked from the venue object from the DB. Then in that web page, I could make this sort of venue a lot easier because I could just place out this layout manually and style with different div elements or make an interactive javascript map, attach a button and make a call using Jquery/Javascript to my native android app.
What are your opinions, is this a feasible solution?
To be honest, an interactive seat map development was the most challenging task I have ever had in my development life. But some how I have done it for an asymmetric seat plan.
This type of work can be achieved in following two ways.
1. Using GPU rendering - Much easier process as almost every device has GPU by default. It detects the interaction point and check it's RGB value to detect the right path has been interacted and return this through client interface (with some drawbacks). e.g: Webview interacting Js interface in android and others.
2. Using CPU based drawing - Draw each and every path on the canvas and repeatedly it need to check the touched/interacted point is inside the paths or not. It will use more the CPU if paths are more complex to render/draw on the canvas for every single interaction. (hug CPU usage and some other constraints)
I am tired of searching some library in android which is very useful like Macaw in iOS development. This library handles the interactive path inside a svg file and help to interact with the client side.
Anyways for me, neither of the two options are not feasible though. I will go with importing/downloading .svg file to your android application and make it interaction using JavascriptInterface in your app. Unfortunately, this is less worse solution that I have found out so far.
UPDATE:
Here is my approach to make it workable. See my medium blog post. Hope it will help you.
This question has been bugging me for some time. I've already developed a couple of apps on the Android platform and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable? Or should XML files be the go-to approach? I usually find XML a more tedious approach and often, these layouts don't look the same on all devices. I just don't get it. From a professional viewpoint, has anyone really been able to develop apps with complex views purely using XML files? This question is killing me because Google recommends using XML but the UI never looks the same on all devices unless done programmatically. Or am I doing something wrong?
Note that I'm referring to Android 2.2 and 2.3, which majority of the users use.
I use XML layouts on pretty much every fragment and activity of every app I write. I very rarely see any need to create Views dynamically, tho configuration of ListViews, showing/hiding views, etc needs doing in code. For me the advantages of XML are:
Ability to use layout editors (Eclipse)
Easier to preview layouts
Possible to benefit from auto-localisation of layouts
Easily maintain different parallel layouts for difference devices (screens)
Can get a sense of the layout by looking at it (easier than code)
Easy to break layouts down into pieces (fragments, includes, etc) to remove duplication
Keeps a separation between the visual design, and the functionality behind it
I can't think of any good reasons to put all my layouts into code - that sounds like hell.
I expect the reason your layouts don't look the same is because your XML is not defining the layouts correctly. Bear in mind the Android tools convert XML layouts into code, so there's no inherent problem with using XML layouts versus dynamic - both end up as code.
OckhamsRazor,
The answer very much depends on your needs, flexibility, and knowledge. The first thing to understand is that every Layout, whether created via XML or programmatically can be tweaked specifically or made to conform to many screens via properties.
... and somehow always find myself resorting to Java code in order to construct the layouts. In a professional development environment, is this acceptable?
Yes, it is. Android makes those available so you can do just that. However, the benefits of managing layouts via XML include standard MVC segregation, simpler debugging, and an easier time modifying the resource, if needed. Additionally, you may maintain multiple copies of Layouts depending on device configuration easily.
... has anyone really been able to develop apps with complex views purely using XML files?
Absolutely! There are some amazing programs that fully utilize XML rather than programmatic views. The key to them is how much information (that is non-standard view properties) is required from parental Views. Even in those cases there are ways to pass that information provided you know where and how to do so.
Or am I doing something wrong?
I don't think so. Honestly, I've run both ways depending on need. I'd say it really comes down to your lack of knowledge of the quirks. But the job is to get the job done. Here's an example: There are some times when I don't know how big everything needs to be until its run on the device, and there are times that I make the device conform to my layout's needs. Ultimately, I use the following chart to make my determinations.
Do I need information from parental Layouts that is aside from view properties
Do I need to dynamically size more than one element independently.
Is the View type pre-determined or will it change as well?
If the answer to 2 out of 3 of those is "yes", I will use some level of programmatic layout. If not, I will go pure XML. That being said, programming is one of those professions that encourages ingenuity (provided it is safe) and nearly anything can be accomplished in any number of ways. Ultimately, I'd say do whatever makes your job making quality apps easier.
Google makes its recommendations based on their own knowledge of software programmers and their general practices. They also created the platform, so they know which things are optimized in which ways. Its all about experience and we all have our own. If you have trouble utilizing XML, its worth taking the time to figure out the quirks simply so that it is another tool to utilize. Also, it will give you the information you need to answer this question for yourself.
To sum things up: I could say chocolate is better, but if you like vanilla, you'll disagree. Be aware of the drawbacks and benefits of each and take the time to learn how to accomplish the same tasks with both methods. It will make you a better programmer and give you a better sense of when to use which technique.
Hope this helps,
FuzzicalLogic
I typically do a lot of work with highly customizable UIs, where large portions of it need to be done in code. That being said, wherever possible I try to use layout fragments and inflate them, so as UI sections are added, removed, or rearranged I'm still just doing some of the layout, not all of it.
That being said, it's not that hard doing layout via code. The big advantage to it is compile-time checking. I'll find issues that way faster than using the preview pane. The preview pane can be nice for initial layout, but I use the Hierarchy Viewer for figuring out why my layouts don't look right.
It really depends on what type of project it is, or piece of a project, and what type of programmer you are. Some people just prefer pure code, while others like leaning as much on other tools for design as possible.
XML definitely has some benefits, like being able to switch between interface designs quickly. For specific design themes that are repetitive, is definitely useful for most programmers.
I personally prefer doing everything programmatically, and it is quicker for me to develop than writing XML, with the libraries and classes I have created. XML is quicker straight out of the box.
As for performance, there really isn't a difference worth mentioning unless you are using the same view so repetitively, at the same time, to the point that it no longer fits on the screen many fold. I did a test of how many text views Android could render on a Moto X - Android 4.4, and it couldn't get much over 5000, but there is never a purpose for that. If you are at that point, you are either need to dynamically load and unload data or are just doing something very wrong to begin with.
So learn both sides of it, definitely get to know the pros and cons with your style of programming, because there is no right answer for everyone, and let loose and have fun.
It is much better to separate the layout and put it in the xml file. I occasionally have to adjust the layout in code, but it is always an exception and only when I determine that it cannot be done in the layout .xml. If you use the layout views correctly, the application should look very similar on all devices.
I have android application that is written "regular" way. layouts, java, APK.
Now, depending on some factors I want data to be presented differently to different users with different preferences, etc. Doing it using XML layouts will be very problematic in couple of reasons:
Upgrade issue - we have bunch of users and they not good at upgrading.
Hard to maintain and code.
So, I'm toying with idea of "templates" where we can serve templates from server and just use device to generate those.
Web app won't work because our data available offline in case there is no connection.
There is buttons and stuff that user can press to call regular Activities and do things.
I envision something like:
HTML 5 template with {tags} that I will populate from data. I will receive tempaltes and data separately from server. I will merge that data and display on UI.
Now my question is how do I:
Display HTML5 inside Activity
Intercept button push in HTML in my Java code?
Is this bad idea to write something like this?
It sounds reasonable to me. You can use a WebView for displaying the content. Your app can manage a cache of downloaded templates and other content and display it in the web view either from the web site or from the cache if offline.
I think your objections to layouts are offbase. You really might be better off with layouts. Here's why:
Your app can be set to auto-update by users if you do not change permissions. But pushing updates to your app will remain an issue unless your app is entirely web-based. (not a bad approach by the way) But so long as you have a native app, you will need to push updates from time to time.
And as far as being hard to maintain and code, layouts are specifically designed to make this type of customization manageable. You can break pieces of the layout common to different settings into separate files, and add them with includes.
You can use fragments to adapt to a variety of form factors.
You can serve up different layout based on screen size, language, orientation, or any of a wide variety of variables.
Check out some of the series on layout tricks, and get more familiar with being a layout power user. I think in the long run it will save you a lot of effort, assuming you don't switch to making your app a web app instead.
http://android-developers.blogspot.com/2009/02/android-layout-tricks-2-reusing-layouts.html
http://developer.android.com/resources/articles/layout-tricks-merge.html
http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
http://www.curious-creature.org/2009/03/16/android-layout-tricks-4-optimize-part-2/
Google: Android Layout Tricks.
Great stuff.
Another benefit: Compiler checking. No broken functionality because a variable or field has the wrong name. Not the case with HTML.
Another benefit: works offline too with no messing around.
And last - you will have a non-trivial amount of work attempting to get this hybrid HTML stuff working the way you want, and then have a very unusual and custom code base that nobody here on Stack Overflow will be able to help you with. Stick with Layouts and there are lots of experts who can help you tackle the stickiest layout puzzles.
I'm working on an app that involves displaying comments from a website. These comments are threaded on the original site, so I'd like to replicate that experience within the app. I know that Android has an ExpandableListView, but it only does two levels and I was hoping for more.
Each top-level content would be aligned to the left. Replies would be indented by x units, replies to the reply would be indented x*2 units, etc.
Additionally, I'd like the ability for the user (or even the application code) to minimize/maximize threads. This would be particularly useful if the first comment has 8724 replies - you could just minimize the original comment instead of scrolling endlessly until you reach the second top-level comment.
What is the best way to present this multi-level list to the user? Are there any native/third-party classes/libraries I can use, or would I be better of coding this list in HTML and displaying that to the user instead?
I don't really think you should use a tree for displaying thread. Device screens are too small for this kind of widget. I would prefer multiple activities for displaying different levels of the thread. But I'm not a UI designer so my opinion may be far from the ideal solution.
EDIT: Here's an open-source tree-view widget: http://code.google.com/p/tree-view-list-android/.
Can someone point me to an Android example with source that allows the user to scroll through the contents of an xml file that contains text entries (preferrably with arrows on the side of the screen that allow previous/next type of interaction)
I've looked through the examples on the Android site and didn't see anything similar. Any help would be GREATLY appreciated (I'm an Android newbie but experienced Java developer)
I seriously doubt you are going to find a nice Android walkthrough of exactly the problem you are trying to solve, so you'll probably need to extrapolate from a few different guides.
Parsing xml is not substantially different from parsing xml anywhere else. This guide talks through the 3 different ways of doing so. Depending on how large your xml is, you can decide which makes the most sense for you.
In terms of UI, not sure exactly what you are looking for, but a ListView is often a good way to display large chunks of data. See Hello ListView.
Or, if you want a single text area that scrolls with 2 buttons, see ScrollView api. Its pretty simple. Common Layout Objects is a good guide to basic layout. You could probably accomplish what you want with a few nested LinearLayouts, or a RelativeLayout. If you post an attempt, people can help you fix it up.