I want to set the active tab in a View that inherits MvxTabActivity from the ViewModel layer. Is there a suggested means to accomplish this or is there something in the MVVMCross framework I can use that I am missing?
My only plan at the moment is have the View send messages to the ViewModel when the tab changes and have the ViewModel send a message to the View when it needs to change the active tab.
I would much rather be able to bind properties from MvxTabAvtivity to the ViewModel though. E.G. the MvxTabActivity could have an "ActiveTab" property which is a simple string that names a tab and can be two-way bound to a property on the ViewModel.
This isn' out of the box behaviour.
But you can try to do this in several ways:
using messages (as you suggested)
using a custom presenter and send changepresentation hints - custom presenters are introduced in https://speakerdeck.com/cirrious/presenters-in-mvvmcross
creating and using a custom binding - https://speakerdeck.com/cirrious/custom-bindings-in-mvvmcross
I'm also sure other ways might be available.
Do be aware that the concept of changing tab might not fit well in all platforms - eg its unusual for a wp pivot or panorama to change item.
Related
Why do I need InverseBindingAdapter in Android DataBinding, When should we use it?
The word Inverse is really saying everything you need to know, if you think of what DataBinding is actually doing.
If you enable DataBinding for your Layout you can perceive it as a pair of two things:
View (all Views included in <layout></layout>)
Model (all variables included in <data></data>)
Regular DataBinding makes sure that a change in the Model will have its effects in the View. It is invoked by #{expression}.
Inverse DataBinding makes sure that a change in the View will have its effects in the Model. It is invoked by #={expression} (the = char is essential here).
If you think what are the ways to make a change in the View, those can be:
Changes in content (e.g. text in TextView)
Changes of checked state (e.g. in RadioGroup)
Changes in focus
...
Some of them are enabled by default and for others you will need to write a custom InverseBindingAdapter. More on that here.
If you still need more information on that topic I suggest you watch Google I/O 2016 presentation on Advanced DataBinding.
I've got a lot of experience with Java and C#, but I'm new to Android. I mainly use C# because I am enamored of the Control hierarchy. I love the plug-and-play of the ontology. I'm trying to understand the ontology in this new paradigm and I may have been given some false information.
With respect to Apps, that should be the largest component. Within the App, there may be several Activities. An activity can display a number of Fragments. AppWidgets appear to be a special case as they exist as a component of the App, but are shown on their own. And I was told that you can extend Buttons or ProgressBar to create your own components which again appear to be called Widgets.
As I said, I may have this completely wrong. Ideally I would like to create my own widgets which I can put on a Fragment, an AppWidget or an Activity; any of which I might compose into an App. All the online sources I've found only discuss Widget in the sense of an AppWidget? Was I given incorrect information? Can anyone clarify the ontology?
Thanks
"Widget" is a bit of an overloaded term. You will probably have better luck if you search for tutorials on "custom Views" instead. I'll include a brief rundown of various terms and what they mean at the bottom.
A custom View is pretty much anything that extends the View class (or any of its subclasses) and isn't part of the framework. Custom views can be used wherever typical Views are expected, e.g. in layout files or directly constructed in Java. One thing to note: only certain Views can be used in an AppWidget because they are running in another process outside of your app. This means your custom Views cannot be used in AppWidgets. In my experience this tends not to matter too much.
App: An application. Contains components, which are defined in the manifest within the <application> tag.
Activity: One of the four application components. Nearly always has an associated UI, composed of a hierarchy of Views.
Fragment: A framework class that helps modularize your application's code and UI. Fragments can be attached to an Activity and can contribute some UI to the View hierarchy of the Activity. They are entirely optional; you don't have to use Fragments in your app, and you can attach a Fragment without it contributing any UI to the Activity.
View: A UI component, such as text (TextView) or images (ImageView). These are also referred to as "widgets", and you may notice the framework classes are found in the android.widget package. Some views contain other views, so that you can build a UI hierarchy; these will extend ViewGroup and are referred to as "view groups" or "layouts" more or less interchangeably.
AppWidget: Something the user can add to his or her homescreen. This is provided by the app, but is not one of the 4 application components mentioned previously (it is managed by an application component, namely a special subclass of BroadcastReceiver). Most people colloquially refer to these as "widgets" because it's shorter to say and launchers used that terminology as well, thus conditioning users to it.
I am working on mvvmcross framework and try to learn it. I have some difficulties when to develop Android project.
I have a main page where everything happens, and I want to put a Login Screen Model on top of that. I do not want to do them as activities because I do not want to destroy the main page to show login page. I just want to show a model on top of that
In iOs this can be done by using Presenter. How can i use the same method for android? Any suggestions? Thanks in advance.
I'd use a Presenter for this too - just use that presenter to show a dialog or fragment (or dialogfragment) rather than an activity in this case.
The default Presenter MvvmCroos provides in Android is Activity based - but it's easy to override it so that it shows different types of things in different scenarios. Search for custom presenters in Android MvvmCross for more info (I'm on mobile typing right now - so can't easily add links)
I am new to android development, and we have a very specific requirement.
We need to change the content/layout/flow of the app on the fly. For e.g. we have a layout which consists of some images, textarea and textboxes. There might be a request coming to change the textarea to a textbox.
We thought about this and are thinking to provide the apk with a json/xml which will contain all these changes.
My question is will it be possible to re-draw the objects again dynamically and change the content?
Yes this is possible. You can dynamically design what has to be displayed in your Activity UI screen. If you feel there are only 2 or 3 different UI screens that would be repeatedly used, then you can have XMLs for these screens and you can just change their labels in OnCreate() of Activity class before rendering. LayoutInflater class would be helpful here.
When you design a Android Application with Activities and Fragments your XML layout definition is always static. If you want a true dynamic layout structure you should use a Web View with a HTML content pointing some URL.
As Rahul says, another approach is to manage the "default cases". For me that is the standard way to design an Android Application.
The dynamic content (values) can be done with a simple http call to server you can get values for your views.
The navigation could be handled by switching Intents, but, definitively you have to associate these intents to UI elements like buttons in the most cases, and ¿How you can do that if your layout is changing over time?.
I think, that the WebView could be a very easy solution for your problem.
Does the Android platform lend itself well to a particular style of UI programming like MVC or MVP? Most of my UI experience is with spaghetti code on a very old embedded device or in GWT with MVP so I do not know where to start.
The MVC Pattern is more or less pre build into android.
You have three layers consisting of:
The Model Your data classes, Content providers etc. wrapping all your data.
The Controllers Treat all your activities as controller classes. Don't do anything in them that looks like business logic or data persitance. Just react to events from the model or the user and forward them to the correct layer.
The View Often the Activities are called the view because there it is the java code that is closest to the views. But in my opinion the view layer in Android is mostly defined in xml. You define your buttons, images, state changes etc in xml and then connect it with your application through your Activities.
There are some simple rules to follow to have a basic separation of this layers.
Define as much of your UI in xml only
instantiate Views yourself if there
is no other way to achieve something,
don't change the graphical state of
views from code, for example don't
change the background of a button if
the button is deactivated, or the
color of a font if a button was
clicked, do all this through stateful
drawables, and selectors in xml.
Don't do any data saving or logic in
your activity classes. Call to extra
model classes for this purpose. This
will make your activities clean and
short
If you want to change your data think
about going through a full
controller changes model -> model
informs controller about changes
-> controller changes UI cycle instead of having the controller
change the model and the UI
directly because other observers
of the modes may not be notified.
I do not know if the Android lends itself well to a specific design pattern when it comes to UI development per se, you can certainly use a particular pattern if it helps.
When in doubt you can check out the standard User Interface Guidelines and see what the guidelines are for particular interactions.