(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.
Related
And many thanks for your help on this !
I would like to do an application where the main menu is like a long (very long) scroll view with some buttons to select different levels. The goal is to have custom buttons for level and custom styles for each part of the menu (like different worlds).
But I don't know how to do this easily (maybe) and efficiently (for sure) ? I though about a long ScrollView, but the performance could be really poor. Or about a ListView / GridView with a very custom style ?
Do you think it is needed to include a full game engine to achieve this ? Even the rest of my app does not need it ?
I found some inspiration apps which already use those kinds of menu :
HeadSpace App
Score! Hero Game
Or even a less styled one :
DuoLingo App
Thank you so much for your ideas, and hints on this !
Have a nice coding day !
I think this is a very personal question and decision; I mean: this depends on you, your preferences for your own game, is not a technical question. Personally I like your designs, but I think that "a long (very long) scroll view" could be slow and too heavy for the player. Think on the game experience, and the way you make it easier to interact for the gamer. That solution would be so slow to get the last levels, almost irritating. IMO, it is better to have one button for each world, and each of them guides the player to the levels inside that world. There you can use a GridView, customizing that, ordering buttons on zig-zag... But this is if you can repeat the levels or replay them; if is necesary to have that. If it is not necesary I woudn't show that as main menu.
Again, this is a very personal question and decision, not technical; and here people like me can give you a subjective opinion. It all depends on your preferences.
I have a very simple app which runs great on the PC, but runs 'acceptably' –not by much though- on my tablet (Samsung Galaxy Tab 3, SM-T210). It’s a very simple app so I thought that it would have ran great from day one, but it didn’t. I’ve seen some really resourceful applications –mine cannot even compare to them- running very fast and smoothly on a tablet. So I’ve been wondering how to accomplish that.
I’ve heard that you can accelerate your flex application using Stage3D, Starling or Feathers. I think with most frameworks I would have to rewrite part of my app because I would have to use the framework’s components to make the app run faster. I don’t know if I’m correct by this though. Is this correct?
Is there a way to accelerate my Flex Mobile app using one of those frameworks without having to rewrite a substantial part of my code? If so, can you tell me how?
Thanks in advance for your help.
Regards,
Sebastián
NEEDED FOR SOLUTION
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
In my Flex-Mobile app, I haven't tried using any frameworks. In order to optimize my application, I am doing the following tips:
write item renderers on AS
subclass LabelItemRenderer or IconItemRenderer
avoid complex bindings
set autoDrawbackground to off
Use BitmapImage over Spark Image
use PNGs over JPEG or GIF. it takes less image decoding and rendering time
Text - Use StyleableTextfield (can be use only in AS)
write skins in AS (extend MobileSkin)
write custom component in AS3 not in MXML
setElementSize is cheaper than setting width and height
setElementPosition is cheaper than setting x and y properties
use light-weight components (i.e. Label)
use cacheAsBitmap property
components that are not changing frequently but are redrawn often
can be cached as Bitmap to optimize rendering time
don't use BorderContainer, use Group + Rect
reduce number of nested Groups
use Scroller.viewport instead of Scroller.verticalScrollbar
Do you have Lists in your app? You could rewrite ItemRenderers etc.
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
After trying to make sense of the Metrics and Grids page of the (fairly new) Android Design website, I gave up on a lot of things. So, basically, I'm trying to find the original layouts that are used in Android 4, so that I can apply the same concepts.
To make this question more objective and not fail under the "too broad" axe of stackoverflow, I ask you for the layout that is used to recreate, exactly and fully, the examples on that page. Did Google provide them in the samples? Maybe a well known didactic repository that strives to conform with standards?
Just as an example, it's not clear what to do to recreate the "48/3 metrics" (16/16/16) in order to make the text fit in it. What if I want to use 1-line of small text? Would it be 16/wrap_content/16, or 16/16/16 to make it consistent with other layouts around the set? What if...
I believe this would not only help the small devs, but also and most importantly, help standardize the look and feel of apps in Android Play. The site is a good start, but far from ideal.
Added details
I never asked a question with this much upvotes, and I didn't even expect that (I have other questions that I regard as "better", but by far not as many votes and favs). Not that I care about votes, of course, but that is to show that there is a great demand for what I'm asking (a bit of an ad populum here, but still...).
Replies to comments
#Ricardo Amaral:
I'm indeed sorry if I wasn't clear enough:
Mandating a standard and requesting unambiguity from it are different issues. One of the reasons I like Android is the degree of freedom we have, so I'm very much aware of the impossibility of mandating most of the common practices.
I believe it relates to the concept of "reinvent the wheel" within the concept of freedom.
Again, those were just examples. Some things are not clear... which are paddings of the outer container, and margins of the inner views? Many times that makes a difference in selectors, dragging etc. etc. etc., and that again translates into a familiar look and feel for the user. One thing feels like splitting hairs, but it quickly adds up to a lot of small differences. And the user notices it... it looks like it lacks that last "finishing touch".
#Michael Slade:
I know they're examples, that they may have been wireframed from templates. As said, I'm already reusing code from the SDK, and I know they're just examples and that we can deviate from them. Again, after all this time, nobody answered.
Optionality benefits from precision. That's what I'm trying to say and ask. Because it's a recommendation doesn't mean its guidelines can be whatever you want them to be. If you do that, it's not the recommendation anymore. That's the whole point of recommendations, by the way: provide an implementarion theory without forcing anyone.
Thanks everyone!
Hate to break it to you but it's likely that the images on the page you like were created with a drawing program, and there are no example to go with them.
Without someone actually going to the effort to create samples for you, your best bet is to go through the samples that come with the android SDK - they will follow the guidelines in most cases.
And remember, they are just guidelines. At the end of the day it's up to you to create a pleasant and smooth user experience, however you see fit.
What considerations should one be mindful of when constructing a GLSurfaceView-centric UI?
This is for a game and the bulk of the UI will be an intro screen (start, options, about, exit) and a level selector screen. I've put a lot of time into the rendering/animation for the game using OpenGL, and I'm no graphic artist, so taking the OGL UI route seems to make sense to me. But I'm an Android novice and need some outside input. Thanks for reading.
There is nothing wrong with that, especially for a game. The only problem is that you will have to do everything yourself. Most games seem to be doing this.
Due to the ease from which one activity can start another, I would say it is worthwhile to abstract your options and level selection from the game itself. If you're unfamiliar with starting activities and/or passing information between activities, there are plently of good tutorials and examples to help. You could try the ubiquitous Notepad tutorial if you haven't already ( http://developer.android.com/resources/tutorials/notepad/index.html ).
The advantages of this method would be to leave your OpenGL/game Activity less cluttered, and that you would be able to use tried-and-true Android UI elements instead of building your own from scratch.
I've been through the Android tutorials - these do a good job of introducing how we can hand-roll an Android user-interface. Actually, I do not need that level of control right now... I'm looking for something simpler...
I'd like to make an Android app which will mainly contain a number of standard UI widgets, nothing particularly fancy. Having done some VB development a long time ago (yes, I know it's crap!) - I particularly like the ability to paint user-interfaces with an interface designer and then add in the relevant callbacks via the IDE. I'm using Eclipse, so for now solutions requiring net-beans or other IDEs are not particularly helpful.
I'm well aware that this practice often produces sub-optimal code, and less than beautiful interfaces. That's not really a concern here. I just need to produce a certain effect quickly in order to prove a concept. There will be plenty of time later on for optimization if my idea is good enough.
If you create a layout xml file you get "drag/drop" for the activity layout. It's not perfect, but you should be able to accomplish what you're asking for.
How you were used to VB development won't work out for you.
You will have to create your interface in XML, and put events to the objects by code. There is DroidDraw but it won't get you further then the plain inbuilt IDE of Eclipse.
When creating XML layouts think like it a HTML layout, nested objects, tables/linearlayouts etc...