[Q] How to develop an efficient custom User Interface like Sense UI and others - Design, Prototyping, UI, Graphics

Dear XDA colleagues,
I recently bought an Android phone based on the MTK6577 engine. In order to improve my skills as developer and programmer, I’d like to develop a new custom User Interface like Sense UI or others. I have my own drawing and transitions already in mind, but I need some useful guidelines in how to proceed:
1) Is Java or C++ the best language to code a new UI?
2) What tools do you recommend to use for best productivity?
3) After Project Butter debuted in 4.1 with enhancements in 4.2, are there any ways to push most of the UI transitions/animations to the GPU rather than CPU? Would that extend battery life?
4) What other coding/system parameters are important to develop an efficient and smooth new UI?
5) What about scalability and easy porting to the future Android releases?
6) If you were to outsource to a SW company such a development, what would be the key requirements (other than cost) you would be asking for?
Thanks very much and looking forward to reading your answers!

Related

Google risks OEM wrath for unified Android UI plan

Conflicts of interest with Android supporters helped kill Google's Nexus One project, but that is not stopping the search giant embarking on another bid to keep Apple-style control of the Android platform. Google is reported to be planning a unified user interface that will be imposed across Android products, ending the fragmentation that dogs the system, but also restricting partners' development of their own user experiences.
Full story HERE
if the UI makeover is any good then I wont mind but I do hope they dont make it harder on HTC to make sense for gingerbread as I quite like Sense UI.
I'm not that fussed on sense to be honest. I could take it or leave it.
I just hope that Google don't start to push people away by trying to monopolise everything. I can't imagine that HTC would be happy if they were having their lives made difficult by Google.
HTC have made an excellent phone in the desire, and if things like this make them think again about a new release using Android then it can only be bad for all of us.
True.
Android is open source so Google cant ban anyone from making thier own UIs so in that sense should be fine. if they do start to monopolise then yeah I will get worried as thats going the apple way.
This depends on the implementation if we (at least I) should take it as good or bad.
Good: google unifies the UI but also allows others (developers) to make their own UI and doesn't make hard the implementation of personal UI. In the end, after Froyo, google needs a nice and unified UI. Froyo brings many things which are needed, now the only thing lacking is nice and unified UI.
Bad: google unifies the UI and doesn't allow nobody to make their own UI. Then they will become like apple and I will personally refuse to purchase anything that has to do with them. To speak the truth, I chose the Android (Desire) device only because of Android openness. If someone takes that away from me, I will take my 500 euro from them. Simple as that. That is the least I can do.
I know this sounds terrible but to be honest I have no problems with Google semi 'monopolising' Android. Unity is so important for a mobile OS IMO. Look how far Apple has got with theirs.
Unlike Apple however, I trust Google not to go too far with it all...
If the UI is good, I dont mind.
I hate everytime Google released a new version of Android and I have to WAIT to get it.
Kill that fragmentation ... please ... please Google?
Whether we like it or not, it seems this is the direction that all OS's (i.e. Microsoft WP7) seem to be going in although Google has under gone more radical changes with it's new versions due to being so new and having developed so fast. Despite what that article above said Microsoft with WP7 are stopping (having stopped development of WM 6.5) OEM's from adding custom UI's so that they can roll out OS updates without OEM's getting in the way or delaying them. This means they can have uniformed releases of OS updates across the whole platform and them not be device dependant.
It's not a bad idea as long as they do not completely lock it down and still allow 3rd party enhancements to be added to the core OS with custom launchers and widgets IMO, as we don't all want or need to have our devices all looking exactly the same. But if it means new OS updates reach users faster as long as the hardware is capable that has to be good for both us the users and Android or any of these OS's.
Also remember Google has said after Gingerbread their will be a slow down of core changes to the OS as it just won't be so necessary as it starts to mature and should only require minor tweaks or fixes from then on. That's not saying development will cease just that it won't need to be so rapid and if by then there are a minimum spec being used with less custom UI's any new features should be easier and faster to apply to all the devices.
-------------------------------------
Sent via the XDA Tapatalk App
i think that what should be done is a unified UI by google which many users like but it will be awsome if their way of customizing is on top of the main core files and can be customized bu 3rd parties too. so there will be faster updates and the possibility of customizing it. something like a folder with the customizations that will be used instead of the system defaults......
Yes....What should I say????......
If(google==apple)
cout<<"**** THEM BOTH";
else
cout<<"Long live google!!";
That has to do it!(c++ style comment)

[Q] How Does the Android OS Work?

Disclaimer: I am only a flasher. I do, however, contribute to the forums, donate to devs and also use the paid version of good apps.
My question is: How does Android work on our phones?
You have hardware (HTC Incredible); you have a carrier (Verizon, in my case); you have an OS (Android, obviously); you have a radio; you have a ROM; you have a kernel; you have themes, you have skins and you have apps. How do all these pieces interact? Just curious.
This is a really good question that should be answered in laymen's terms. I'm surprised it hasn't been answered yet.
I also thought it would have been answered by now. However, I think the developers (who would be the best folks to answer this question) are busy working with the Gingerbread source code to build new ROMs for us.
This is what I have figured out so far but I'm not sure if my analysis is correct:
After selecting your hardware and carrier, the OS is the most important element. Most of us are currently on Froyo (2.2). I have seen some screen shots showing the OS version to be "2.2.1" but I am not sure why. Google (I think) has released the source code for Gingerbread (2.3) and the developers ("devs") are hard at work producing new ROMs as I post this.
I gather that it is best to stay away from trying out different radios ("basebands"). Most of us are using 2.15.00.07.28.
I think the ROM takes the OS and re-works the user interface by adding, removing and changing the various screens and "features" of the OS. For example: the ROM can be written to take out the stock music player and substitute a music player that the ROM developer prefers. I think this is called "baking in an app". I believe the ROM developer can also create an overall "look and feel" that can be quite different from the stock OS. For instance, the ROM can be "colored" in black and red (rather than the stock green) and the stock font can be changed to something the developer prefers. In other words, the ROM is what you see and use on a daily basis.
Now this is where things get a little fuzzy: the kernel. I think this is kind of a behind the scenes element that governs the performance of a ROM. It greatly affects things like battery life, time to charge the battery and the "speed" of the phone. The kernel is where the phone can be "over-clocked" and "under-volted" should you want to do those things. I gather that once you select a ROM, you can try different kernels without changing what the various screens look like on the phone. I believe this is the way most people do it (pick a ROM and try different kernels with it). I don't think the other way really works (pick a kernel and try different ROMs with the kernel).
Next comes themes and skins which really only affect what you see on the various screens without do anything about battery life or the speed of the phone. I haven't played with these much.
Finally, I forgot to put WALLPAPER on the list in the original post. I believe this only appears as a background image on the home screens.
If any reader sees errors in my layman's analysis, please, by all means jump in and correct me. Per my disclaimer in Post #1, I am just an ordinary user and this analysis could be flawed or incorrect in whole or in part.
Everytime I try to answer a question like this, I get too complex about it and leave more questions than answers. Then someone comes along and says "It's like Windows or Linux or MacOS on a PC", and that's that. Well they're right. Those OS's tell the PC's that they are PC's and essentially all OS's do the same things.
Here's my simplified new list:
1) Hardware on phone :: meaningless without OS
-- (android OS - or any other OS)
2) Linux kernel understands hardware like touchscreen, radios, I/O (drivers/modules). Of course it also understands how to schedule processes and all those "kernel tasks".
3) Libraries provide APIs (Application programming interface) to userspace code (like APPS).
4) Userspace (apps, scripts, libraries) provide user control over the phone.
--
Together they work in harmony (we hope) to make the phone realize it is a phone and allow us to use it as such. (well, a smartphone, so many things other than a phone).
Here's a simple example: You touch the phone icon which is in userspace, and it brings up the userspace phone app. As soon (or before) as you touch some buttons, dial a number, it is using the API to the driver in the kernel that actually understands the phone hardware/radio. Also userspace controls GUI which is also requiring API to some form of OPENGL API that is requiring device drivers that get the touchscreen/LCD display. and so on.
--- Hashi
PS: I realize there are a thousand things wrong with this representation, but hey, it's a start. Feel free to fix it up if you're inclined.

[Q] Any benefit of CM7 over Others?

Just curious as everyone freaks out about cyanogenmod... what would be the benefit of running it over, say... Calkulin's rom? I have CM7/9 on my HP Touchpad, and I don't see anything major that differentiates it from normal android?
small and clean.
It's completely open-source (built off of the Android Open Source Project)
Many more options for customization
No need for "rooting"
Built-in theme manager
Consistent default user environment over multiple devices
There are many more of course, but those are some of my favorites. I mainly support it because I am a huge proponent of open-source software, and I enjoy the level of customization without "bloatware" from carriers or device manufacturers.
If you'd like to see a few more specific features, check out the wiki here: http://wiki.cyanogenmod.com/wiki/Features
While I admire the skill and time it takes the devs, I won't run the CM ROMs because it disables dialer codes, and if I want to update my PRL or baseband, I'm forced to install a different ROM to do so.
Sent from my SPH-D710 using XDA App

SGS2 D4 Rom with heavy customization features. Portable?

This was on the front page. Would it be possible to port this feature to our AOSP roms? A flashable standalone would be pretty EPIC (and thats what we're all about on this phone )
http://www.xda-developers.com/android/d4-rom-for-the-sgs2-brings-modular-goodness/
We all like customizing our Android devices. In fact, for many of our 4.4 million members, that is the main reason we chose Android in the first place, rather than going with some unnamed fruit company. It is in this customization that we make our mobile devices truly our own. Many prefer to do the customization with themes and other mods, but sometimes it can go even deeper.
We’ve covered methods of customizing ROM installations in the past using the Aroma Installer. The installer, which is similar to nLite for Windows power users, allows end users to customize how exactly their ROM of choice is installed. However, this requires both a porting effort to your device and implementation into the target ROM. Unfortunately, this leaves many users out in the cold. Furthermore, other users would like a modular ROM that can be tweaked well after installation.
Luckily for Samsung Galaxy S II owners, however, XDA Recognized Developer D4rKn3sSyS has released a CyanogenMod 9-based ROM that includes some modular functionality. Using the built-in control app, you can easily modify things such as battery style, LCD density tweaks, enabling or disabling system sounds, switching recording video format, switching USB mode (UMS or MTP), and much more.
D4 ROM goal is to offer the maximum stability possible, and easy-to-user features, like changing LCD density, Recorded video format and so on. But it’s main aim is allow user to choose what mods he wants, and enable them with just a tap.
Have in mind, that what differs from this rom, is not the base, but the options that can be added via OTA. Some of the features are:
*OTA App for adding features on the air, like:
-Battery Styles
-MP4 / 3GP Recording
-MTP / Mass Storage
-Sound Management
*Minor inbuilt tweaks
*Custom bootanimation
And more
Those lucky SGS2 owners looking to get started with D4 ROM should head over to the ROM thread.
Click to expand...
Click to collapse

Android 4.1 Jelly Bean?

hi guys, i see on all IT News that there is new storm comming! Android Jelly Bean!
Android 4.1 is the fastest and smoothest version of Android yet. We’ve made improvements throughout the platform and added great new features for users and developers. This document provides a glimpse of what's new for developers.
See the Android 4.1 APIs document for a detailed look at the new developer APIs: http://developer.android.com/about/versions/android-4.1.html
Faster, Smoother, More Responsive
Android 4.1 is optimized to deliver Android's best performance and lowest touch latency, in an effortless, intuitive UI.
To ensure a consistent framerate, Android 4.1 extends vsync timing across all drawing and animation done by the Android framework. Everything runs in lockstep against a 16 millisecond vsync heartbeat — application rendering, touch events, screen composition, and display refresh — so frames don’t get ahead or behind.
Android 4.1 also adds triple buffering in the graphics pipeline, for more consistent rendering that makes everything feel smoother, from scrolling to paging and animations.
Android 4.1 reduces touch latency not only by synchronizing touch to vsync timing, but also by actually anticipating where your finger will be at the time of the screen refresh. This results in a more reactive and uniform touch response. In addition, after periods of inactivity, Android applies a CPU input boost at the next touch event, to make sure there’s no latency.
Tooling can help you get the absolute best performance out of your apps. Android 4.1 is designed to work with a new tool called systrace, which collects data directly from the Linux kernel to produce an overall picture of system activities. The data is represented as a group of vertically stacked time series graphs, to help isolate rendering interruptions and other issues. The tool is available now in the Android SDK (Tools R20 or higher) http://developer.android.com/tools/index.html
Enhanced Accessibility
New APIs for accessibility services let you handle gestures and manage accessibility focus as the user moves through the on-screen elements and navigation buttons using accessibility gestures, accessories, and other input. The Talkback system and explore-by-touch are redesigned to use accessibility focus for easier use and offer a complete set of APIs for developers.
Accessibility services can link their own tutorials into the Accessibility settings, to help users configure and use their services.
Apps that use standard View components inherit support for the new accessibility features automatically, without any changes in their code. Apps that use custom Views can use new accessibility node APIs to indicate the parts of the View that are of interest to accessibility services.
AND A LOT A LOT of other features according to Android Developer Community at: http://developer.android.com/about/versions/jelly-bean.html
I was wondering if i could inspire the HTC One X Developers, to be the first one's that this Jelly Bean OS will be developed for HTC One X coz i can't handle the Samsung Galaxy S3 Users with their mods, roms, n stuff.
I WANT TO SHOW THEM THAT WE ARE THE BEST!
Watch this wonderful video at: http://youtu.be/V5E5revikUU
There is already a port from GNex system dump. Also a Nexus 7 system dump was made available so let's see how it goes.
Sent from my HTC One X
realunited123 said:
There is already a port from GNex system dump. Also a Nexus 7 system dump was made available so let's see how it goes.
Sent from my HTC One X
Click to expand...
Click to collapse
Oh, that's good i guess!
I CALL LeeDrOid or CoolExe! they r cool developers so they can port to HTC One X
Development section, done.
Please continue any JB related discussion here:
Jelly Bean (JB) for the HOX - OTA/Information/Update/ETAs/etc

Categories

Resources