I'm a designer and interested in different ways I can handoff animation to Android developers and the best ways to do that depending on a particular case.
1. JSON
I know Lottie works best for animating micro interactions and creating animated illustration, like those on onboarding pages. For a designer it's easy to provide JSON file since it can be generated with Bodymovin plugin in AfterEffects. Developer just gets the file and uses it as is, no more additional efforts for him.
2. Java or Kotlin
UI elements that require complex interaction are usually build with code, like BubblePicker since it has changeable content in those bubbles and different conditions how it can be interacted with. Since design tools don't generate production-ready code designers export video recording from tools like Principle, generate clickable prototypes in ProtoPie or other tools. Designers try different ways to show the idea of animation but in this case all the work is left for a developer.
3. XML
Don't know when developers use this type and if designers can provide it using export from some design tools.
What are other technologies developers use to create animations?
What type of files, prototypes designers should provide for the developer considering different cases?
Android animation API is really diverse, meaning there are lots of ways a developer may choose to deliver an animation. I dare to say this should never be conditioned by the nature or limitations of the provided resources. Let's understand by resources anything that's not actual code: bitmap images, audio files, and even text. Knowing the file types or formats the developer can or wants to use involves communication and you can expect them not to be always the same.
Always provide a video of the animation, unless it can be described with a single word.
The most common animations in android are:
Drawable animations. This type of animation usually happens inside a pre-defined area on the screen and is achieved by loading a series of images, one after the other. Here a common filetype would be PNG images, one for each step of the animation. Probably the same amount of different sprites you used for the video, never as many as 24/s! Keep in mind that to support different screen sizes and densities, different size/densities will have to be provided for each series. If the image is simple Vector Graphics would simplify the job for both the coder and the designer, regular SVGs are supported.
One can also animate on the paths of the vector images, even morph between several of these, as long as the paths are compatible for morphing, which according to the documentation they must have the same number of commands and the same number of parameters for each command....this takes more understanding of the intrinsics of the vector file definitions, if you can see the image by reading the SVG code, go for it!
Another major group comprises the animation (by acting on properties like color, position, size, etx) of the application UI elements. This type may or may not involve image resources, and are usually applied to components of pre-defined types. E.g.: all buttons should have a ripple effect starting where the pointer clicks. Android has pre-defined effects with particular names (flip, zoom), it could be useful to know this vocabulary.
Finally, layout changes are animations that happen when you reorder things around to better convey information or hint the user towards actions. Similar to these are the Transitions, which happen when switching screens but can also be used to create animations that move images around, altering their positions and properties. They are really simple to implement and may require resource files of the same type as mentioned in 1
For reference, check the following which has some code but also illustrative examples:
https://developer.android.com/training/animation/overview
To know how to support different screen sizes, check:
https://developer.android.com/training/multiscreen/screensizes
To know more regarding SVG support in the Android platform: https://developer.android.com/studio/write/vector-asset-studio
Related
I am working on a banner creating app where the user can create custom banners for any purpose. The banner will have text, icons, background, etc. The app needs to provide features such as
Text Editing which includes simple effects like bold, italics, underline, font changes etc. But also more advanced effects
such as envelope distortion, curving, outline etc. Moreover in the
future, there may be more such effects that may need to be added.
Background editing by adding an existing image or creating a background with available options in the app
Think of it as slides in power point where user can add their own text and format it plus have backgrounds. There need to be a lot of customization
I need to decide what tools to use to develop this. The main issue is how to render texts dynamically. The options I have been thinking of are
Using TextViews/EditTexts and other top-level view classes
Using CustomViews i.e Canvas
Using a more advanced and lower-level approach such as an
ImageProcessing library to render text or even something along the
lines of 3D graphic rendering.
I need to make a choice that isn't incompatible to support future effects that may be needed. I am pretty sure TextViews/EditTexts etc won't be the solution here. I am not sure how powerful the Canvas class is and whether it is possible to create such an app by just using CustomViews.
Coming to ImageProcessing or 3D graphics, it may be used to have much more control over the effects by using PixelShading/Transformations etc but it comes with its drawbacks. i.e low level of abstraction and higher development time possibly.
Can some more experienced folks give some insights? Thanks!
Use Image Processing and for different themes use lotte-Animations.
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.
I am trying to put together a fake UI for an iOS and Android device without actually creating all that tedious UI work. Is there a way to mockup the UI from the images somehow? We have the Photoshop designs and mockups so far.
Are there any tools? I've checked Titanium and ForgedUI. While its a fairly simple concept I still think its an overkill to create all that. for instance I have to slice my PSD for the buttons. Plus the data feed has to come from a URL etc.
I just want something similar to Balsamiq Mockups linked screens one to another for an actual demo of a bunch of screens. We want to test the navigation, the fonts and the product concept while development is getting the product ready.
Thanks in advance!
The easiest way would be to use HTML. If you already have Photoshop mockups, you can simply export those to (retina quality) PNG images and add some image maps for navigation. If you add this site to your homescreen, you will have a pixel-perfect preview without Safari's navigation bar.
However, iOS apps depend heavily on animations. If you're going for a native UI anyway, you should consider creating a "real" UI prototype, using actual UIControl elements. While this is more work, it allows for much better UI evaluation.
For wireframing, a couple of options:
For high-fidelity mockups, I would do it in Interface Builder and storyboard, like JustSid recommended. Just don't do the tedious work of hooking up the UI elements.
You could look at tools like Adobe Proto. I've never tried it, but it seems like it might be an option.
For my super-quick, low-fidelity mockups (e.g. digital equivalent of the "back of the envelope" mockups), I personally use my iPad, a stylus, and a drawing package like Sketchbook Pro (use whatever drawing package you want, but I like one with layers). I also put blank device images on my iPad, too.
So, I open up my drawing package on my iPad, start a new drawing using a picture of an iPhone device as the starting point, drop on a new layer (so I can draw on a layer and either hide or discard that layer to instantly get back to the image of the blank device image), and just draw what I want my UI to look like on this new layer. This works great for brainstorming sessions. There's no automatic bridge from this conceptual, low-fidelity mockup to an actual Xcode storyboard, but I can draw a user interface mockup in seconds. I do this not only for brainstorming with designers, but also for fleshing out my own conceptual ideas, myself, too.
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.