I have a project which will be a portal to book a conference room. It will be a private app that will be run on a cheap tablet and mounted in the conference room. The app will just update a webserver backend.
I would like to implement a UI that is essentially a grid. The day of the week will be on the x axis and the hours on the y axis. If a particular time has already been books a different color will show. To book the room you press on the cell that corresponds to the day and time you would like and asks to confirm this.
I have played around with a grid view and table layout and can't find anything that fits the bill so suggestions are most welcome.
I have not used openGL yet would this be a good opportunity to learn about it?
There are many ways you could accomplish a layout like that. Personally I am a fan of using RelativeLayouts. They usually tend to require a little bit more to get setup looking how you want. But it is far easier down the line if you decide you want to make any non-trivial changes to the layout. openGL would allow you to do this, but I think you are better off using the layouts and views provided already. At the very most maybe you'll want to create your own subclass of View that fits your needs see Creating Custom Views if you want more info on that.
Related
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.
I'm creating an app that needs to display a table, with say, 30 columns and 30 rows. I want the user to be able to use swiping to move around the table/spreadsheet. The idea is that probably the entire table will not be visible on the screen, and if it is, it will hardly be readable, so there will have to be some max-columns-on-screen value. Each cell in the table must be capable of being a different color than the rest.
So far, I've looked into TableLayout. This doesn't seem to support different colors or swiping... actually, it does support different colors via .xml, but this isn't changeable at run time, and seems like it would be very messy anyway.
WebView looks to be an option, as I am proficient with HTML/CSS but can't find many resources about creating HTML and CSS content on the fly with android - only loading it; although I can imagine writing a file with the data and then loading it, and deleting the file. Not sure if any of this is good performance wise.
What direction should I head, before I start heading in the wrong direction? :-)
Yes, it is possible (and not difficult) to support different colors and gesture in the tablelayout rows.
I think it is always a wiser choice implementing the native components, once it has a better performance and it has a better layout adjust to different android versions.
Either method can solve the problem, so it's a judgment call based on your goals and requirements.
On the plus side for Android native views:
They are pre-compiled and easier to parse than HTML, so they will load faster, scroll more quickly, and require less memory.
If you intend to write a lot of Android apps you will need to learn them.
If you took this route, a typical approach to draw multiple columns would be a ViewPager with sliding tabs. See for example the Google Play Store app.
It's not the case that coloring native views dynamically is impossible or messy; it's not hard at all but it takes time to learn how, which brings me to the plus side for HTML/webview:
A programmer with expertise in HTML will solve problems faster by just using HTML.
Layouts designed in HTML for an Android web view can be re-used on other platforms.
Again, it's not really hard to load dynamic HTML into a web view. There are a few tricks you will need to learn but that's it.
Making an application for android i noticed that the layout view on eclipse is different from the application layout view on my phone when i run my application on the phone. Talking about the position of widgets including buttons, image view, custom views. The placement is different in the application layout view on eclipse from that on phone. I was thinking that this means it would variate on different models of the android phones on which the application would be run. How can i make my view generic in order to cater this issue so that the position of the widgets be same no matter where the application is being run? Is it possible to cater this issue?
As Henry suggested in the comment, this Android dev article should be able to make all your dreams come true.
http://developer.android.com/guide/practices/screens_support.html
Literary everything you could ever need to know about formating for different size screens is in that.
I did this to generate UI elements which fit on any phone and have abstraction what elements I want to show and how they will look like:
SimpleUi ( https://github.com/bitstars/SimpleUi )
The generated UI (code below):
The complete code to create this Android UI:
I use it in real applications, not only for fast prototyping or dialogs and its well tested over the years. The concept is based on the model view control principle and for most common scenarios there are ready to use components which automatically look correct on any device. I don't say it should be used for any UI (e.g. listviews should be done by hand) but for most usecases this should be quite handy ;) Oh and feel free to fork it and improve it further if you want
(disclaimer: all my life I've been incredibly far from UIs of any
type, shape or form - backend and algorithms were my things, and UX,
unfortunately, wasn't. But there's always a moment when you want to
give it a go...)
I've been fiddling with an idea of a toy project for myself, and as a part of it, I want to implement something similar to Schedule/Day view in Android calendar. Probably best this is explained by this UI mock (admittedly I'm not the best UI designer, but hopefully this would be enough to illustrate my point)
Currently I'm thinking of using RelativeLayout to layout the schedule blocks and redraw background with the grid (hour lines). I fiddled a little bit with RelativeLayout and arguably this might do the trick, but I'm very unsure about the background. Do you think this approach would work? Is there some better way of doing it?
Many thanks in advance!
I was looking for the same thing, and could find no good options, so I created the yadview project (https://code.google.com/p/yadview). yadview is a fork of the DayView schedule in the AOSP Calendar app, but has been reworked significantly to allow for integration into your application.
Sample screenshot of this View in an Activity:
I'm working on a project very similar to this! The idea is to have a sense of priority to the items. That way, the user can collapse the views into a single executable list of tasks, not worrying about the things that are lower priority until they need to cancel the higher priority events, at which point, the lesser priority events seamlessly fill in the blank space. Feel free to message me directly, as I'm sure there aren't many who would find our conversations helpful.
I'd like some advice regarding Android UI (in)efficiency. I'm trying to determine the best way to build a particular layout for my app, however I think my initial idea potentially runs the risk of brutalising performance. Basically I have three very similar and related app components, and to configure them, I need user input. The three components share different parameters within a global set. I want to determine a nice, fluid fashion in which to display this input form on the device.
What I'd like to do is simply allow users to use one form in place of three. All three components are related/similar and they share some of the configuration parameters the user is required to enter.
My initial idea is as follows:
Build an extensive layout of UI elements necessary for initial display for any of the three instances via XML. Unfortunately, given the number of parameters organised in rows, this will amount to approximately 50 view objects in total in this case.
Create activity so that the user enters the screen, and understands
they are required to initially choose one of three values from a
Spinner widget at the top of the screen.
By using bitwise comparison operators, simply show/hide the various
controls related to the chosen Spinner value. (Triggered via
Spinner's onItemSelectedListener() )
Create some minor/lightweight animations and so on so they
understand pieces of the puzzle are being added or removed to
reflect their choice.
Alternatively, a second theory involves using three different activities, and saving state between the three, passing parameters between them... Perhaps I should abandon my initial idea and use something along those lines? A third alternative?
The primary motivation for doing this instead of just breaking it into three separate forms is it should allow for users to experience a consistent UI with minimal frustration if they choose to re-think their initial selection. Using the above, if a user fills out half of the form and decides they'd like to use an alternative option from the Spinner, their information is obviously retained, because they'd be using the same view objects.
I would like to ask you all for a little advice on how I can achieve this without risking too much of a performance decline on typical, mid-range Android devices (by that I mean handsets most users own, from Froyo up, and in particular those from Gingerbread up). I'm concerned because I only have access to one test device and it's a HTC One X handset, and that's obviously an extraordinarily poor choice for getting a handle on how capably most mortal devices can render more complex layouts.
I'd also appreciate any guidance regarding tips for optimising performance... I understand from scouring the community and Android's developer resources that rendering some layout objects is more exhaustive than rendering others, and I should opt for LinearLayout where possible (as opposed to RelativeLayout for example). Is there any definitive resource for comparing the performance of UI options? I'd very much like to spare you the time and effort, and go and acquire the knowledge myself.
Thanks in advance for the time and effort. Cheers.
Edit: I guess I should mention that if necessary, almost none of these views need to be drawn to the screen when the activity is initially loaded (the first time anyway)... If desired, I can initially load only a few views, and the Spinner widget. It'd be like loading 'No option selected' instead of Option 1, by default. The impact on the user may actually be minor if the device is sluggish because their device won't actually have to draw more than a mere handful of view objects when the activity is loaded. At any one point, the device is probably only required to render and subsequently display about 30 view objects at any one time. I guess the critical issue is, "Will the user experience a hang or a delay if their phone is struggling to load a lot of XML, even if it's not displaying it all when the activity is loaded?"
+1 for great effort on the question. My personal suggestion is that you stick with your second theory. Keep your data separate from the views -- store the entered values somewhere such as SharedPreferences or a database -- and have three different layouts (one for each form). On creating your Activity, check each common field for a previously stored value and populate that field if one exists. Trying to do something like the first list, while maybe clever, would hardly be ideal.
I think it would make more sense to just develop layouts for the different device screens. You can do this, and put different layouts in different folders. Here is a great article that talks about some of this. I wouldn't give people the "option" to choose. They may not always know the answer, so it is best to let the phone decide which layout to use.
Here is the article:
http://developer.android.com/guide/practices/screens_support.html