I don't understand why google decided to not implement support for custom views or even support for the ones bundled in the support library when designing widgets, and instead it decided to rely on RemoteViews
Widgets are such a big part of users interaction with the app, I'm sure many developers found themselves forced to change plans due to this limitation
Is there a specific reason why this was made, maybe related to performances or?
For example, now i would like to implement a recycler view in one widget but I can't, and I don't understand why it has to be so hard to design one and with so much boilerplate code
Widgets are such a big part of users interaction with the app
Few apps implement app widgets.
Is there a specific reason why this was made
Both the host of the app widget (e.g., home screen/launcher) and the publisher of the app widget need to agree on what UI elements can be used and how they can be configured.
For example, you seem to want to use a RecyclerView. That's fine, however, your app does not render the app widget. The host is the one that needs to render the UI of the app widget. So, if you were to use a RecyclerView, your app widget would fail on all hosts that lack RecyclerView support for app widgets. This includes:
All hosts that have not been updated since before RecyclerView was introduced (e.g., home screens on older devices)
All hosts that did not bother to bundle in RecyclerView in their apps
All hosts that did not bother to bundle in whatever the code would be that would cause app widget rendering to support RecyclerView
This coordination gets very complex with hundreds or thousands of hosts and tens or hundreds of thousands of app widgets.
Plus, where does it stop? You think that using RecyclerView is reasonable, and the next person will think that using Facebook's Litho is reasonable, and the person after that will think that using some obscure custom View found on the Android Arsenal is reasonable.
The simple approach for ensuring this agreement is to use a common definition in the framework classes, like RemoteViews, so there is a guaranteed-consistent definition between host and app widget provider. However, RemoteViews is difficult to change in a backwards-compatible fashion, which is why Google has only done it once to date (API Level 11, with the introduction of AdapterView-based options, such as ListView). And framework classes know nothing about libraries, such as those providing RecyclerView or Litho.
Related
Until now, fragments were the recommended solution for having one screen inside another main screen, for example for list-detail pattern.
Now google has released Activity embedding: https://developer.android.com/guide/topics/large-screens/activity-embedding
With Activity embedding APIs you can take advantage of the extra
display area on large screens by showing multiple activities at once,
such as for the List-Detail pattern, and it requires little or no
refactoring of your app.
Is Activity embedding replacing fragments? or will fragments be a better solution for some cases? If so, for which cases will be better each solution?
Thanks for the post. I was not aware of this capability. As for your question, I think that last couple of lines of the link you posted answersit:
Modern android development uses a single-activity architecture with fragments, navigation components, and versatile layout managers like SlidingPaneLayout.
But if your app consists of multiple activities, activity embedding enables you to easily provide an enhanced user experience on tablets, foldables, and Chrome OS devices.
So, it looks like fragments are the way to go but, if your app is composed of activities that make sense to run side-by-side, then activity embedding may be useful.
Is Activity embedding replacing fragments?
Not really.
(though composables are replacing fragments (and views)).
or will fragments be a better solution for some cases?
With respect to activity embedding, fragments are a better solution in most cases. Roughly 0% of Android devices today support activity embedding, whereas roughly 100% of Android devices support fragments (either through the modern Jetpack implementation or through the older framework implementation). Also, fragments are for more than merely side-by-side presentation on larger screens (e.g., as pages in a ViewPager).
Activity embedding is for developers who:
Have an existing app that is centered around activities, and
Want to adapt that app to deal with foldables and large-screen devices without rewriting the whole app to use fragments or composables, and
Are willing to live with the fact that activity embedding is for Android 12L and higher
(though I think activity embedding is also around for Android Automotive, the "your car runs Android" OS)
When using the layout designer in Android Studio, custom classes that I create which extend the View class show up in the layout designer (picture relevant)
Is there a similar way to make custom classes appear that extend the Fragment class?
My use case is that I'm developing a library which I will distribute to our clients. I want it to be as easy as possible for someone to use this library to place a video player in their own application. I discovered that fragments may be exactly what I need -- something which has a defined appearance, can be trivially dropped into someone else's layout, yet is able to manage its own state, perform business logic, and listen to life cycle events (for the sake of cleaning up video buffers, stopping timers, and de-allocating resources)
However when I tried switching from using a View to using a Fragment, it didn't show up in the palette to be dragged and dropped into my app. While not absolutely and incredibly super-duper necessary, I was really hopeful that I could maintain that as an ease-of-use feature.
Should the (title of various android/ios screens, labels of various form-controls) be hardcoded in android/ios apps OR such data should be brought from the API responsei?
Most of the page/section-of-page has a title. In form with textbox/combo box, we have labels for each of these controls as well. Should such UI information be hard-coded OR brought from the API?
Few questions here:
Pros of having all this hard-coded on android/ios apps: Clean and light weight API data. APIs will carry only the data part and not the user-interface elements like title, labels etc. This would save bandwidth and make APIs bit fast.
Cons of having all this hard-coded on android/ios apps: If we want to change these title, labels in future, we can only do that on the newer version. All previous app version will continue to show the old title/labels only. If we had brought this data from APIs, we can change these anytime across all the versions.
Which is correct approach? Or should we decide this based on the fact if titles/labels can change in future and they need to be changed for all app versions, if this is the case, then it should be in API otherwise they could be hard coded?
Can Apps use firebase to get such information and change it in previous app versions too?
It would probably not be a very good user experience to populate all of the UI elements from API calls without at least having some hardcoded defaults in place to allow the user to initially navigate within the app without waiting for the API calls to retrieve information. Also, if you try to create an app using this server-side UI design you probably want to use mostly web components and possibly even serve up the html to the app because there can be a mismatch between the content (i.e. the text for the labels, buttons, and text fields) and the UI elements themselves. For example, imagine a segmented control that initially was designed to only accommodate two options ("Home" and "Work") and then later an additional text option is added to the list ("Home," "Work" and "Gym").
From what I understand, and activity is equivalent to a "page" in a web app.
For example, the list view would be one activity, edit view another activity, and add view a third activity.
While this works as expected, android activities seem to operate as individual apps--the action bar is different for each activity and so are the menus.
Is my usage of activities above correct or should I be using some other mechanism such as swapping out layouts and views?
Fragments are a core part of activities - not that much different. The use of fragments comes since Honeycomb 3.0 and the idea is an option to split the screen in several fragments at once. For example if you look at the gmail app for a tablet - you have one fragment on the left dealing with navigation and then the next fragment on the right is the list of emails.
On a mobile device, viewing area is limited, so you it could be said that fragments sort of behave like an activity - you interact with one fragment, which triggers another and so on and so fort. But in the end you always reference a super activity of each of these fragments - for example when you want to access the context.
So if you just want to wrap web pages in WebViews, stick with activities. If your scenario might involve developing for both tablets and phones, then go for the fragments.
Alternatively, you can read about the design philosophies of both here:
http://developer.android.com/guide/components/fragments.html
Good luck!
Fragments are to be used when you have common feature across multiple activities. From my perspective you should use individual activities as there will be back-end code to support (fetch and validate data, i.e. business logic). This way you have more modular code. Fragments is a new feature from v3.0.
From what I know, Fragments would be a good option to be able use different configurations/real estates on different devices. For example, if you are on a device with big real estate like Tablets or TVs you can display more content in a single activity, on the other hand for a devices with smaller real estate you can show content based on a progressive manner.
See this: http://developer.android.com/training/multiscreen/adaptui.html
Note that Fragments are supported only on devices running Android 3.0, so you might have to use Support Fragments (See: https://stackoverflow.com/a/6528757/713778)
But Again it depends on your specific needs. I am not sure what your exact use case is, but I would suggest you to watch some Android design in Action for some examples to improve your design and make your app "User Centric" (See: https://www.youtube.com/playlist?list=PLWz5rJ2EKKc8j2B95zGMb8muZvrIy-wcF)
I recently came across this https://www.youtube.com/playlist?list=PLWz5rJ2EKKc-riD21lnOjVYBqSkNII3_k seems provide an in-depth analysis on User Experience.
I would recommend using fragment for web like views. Fragments are pretty snappy compared to activities and reusable.
But before you start, make sure to fragments are good fit for your requirements since they are supported from android 3.0.
You can declare fragments from xml itself or you can create frame layout and add that view in the code itself.
http://www.c-sharpcorner.com/UploadFile/2fd686/fragments/
The above link has a good example tabhost.
I am trying to teach myself the basics of Android dev. At the moment I am experimenting with home screen widgets. I would like to create a simple widget that lists all my bookmarks. Somewhere in my googling I read that ListView is not usable in a widget. What's the best way to display a scrolling list in a widget? An example would be fantastic, but otherwise point me in the right general direction and I can research further.
Thanks in advance,
Dany.
ListViews are supported in Custom Launchers that support the scrollable-widgets extension or in the Launchers since Android 3.0 (Honeycomb). Take the Android Agenda Widget for example, this supports scrolling in Custom Launchers, or the GMail-widget on Honeycomb.
Scrolling widgets in Custom Launchers is described here:
http://www.geekrono.com/2010/08/android-scrollable-widgets.html
Scrolling widgets in Honeycomb and up is described here:
http://developer.android.com/guide/topics/appwidgets/index.html#collections
You can finnd the sources for good working example except for Honeycomb at http://code.google.com/p/scrollablecontacts/
I've only seen a huge list widget on phones with HTC Sense - example. HTC Sense has a widget like that for Stocks, Twitter, etc. I don't think it's a good idea to develop huge widgets like that, because they take up too much space and some phones are limited to 3 screens (screens that you can put your app shortcuts, widgets and etc).
This is a good article on Widget UI Patterns:
Widget Design Guidelines
Seesmic for Android has a 'list' widget with latest tweets:Seesmic Blog
Widget Screen
There's also an article on UI Patterns, based on the new Twitter app, hope that helps you - Link and a video (Android UI design patterns).
Re: user controls (like in .NET), Android Views and in your case 'ListView' is what you might use for your app. You also mentioned .NET (Visual Studio), you might be interested in MOTODEV Studio. It's basically a better version of Eclipse (with Android SDK) that has common code snippets and other cool stuff.