loading different root view controller on starting of an universal app - ios4

I am trying to create an universal app for iOS. I want to load different xib based on device it being run. Do I need to create two separate app delegate classes?
Any help would be appreciated.

No, you don't need to use two different app delegates, but you can: what I've done in some apps is to create an app delegate base class and each the iPhone and iPad versions derived from that base class to implement the different behavior. See the answer of hotpaw2 to this question.
In your Info.plist you can specify different XIBs for iPhone and iPad, and in each XIB you can specify the app delegate class. Either use the same one or different ones, whichever suits you best. See also this article.
This nice blog post also shows how to load different XIBs manually depending on the device being run on.

Related

How do I setup a single application for cross platform deployment using MRTK?

I am trying to build an application (converting rather), that builds into a server (UNET/ Mirror wise), a windows client, Oculus Go client and UWP client. More platforms will be implemented in the future.
Unless I did not tackle this the right way, the Toolkit does not seem to be capable of doing this with just one profile, or maybe not at all.
E.g.: I need the mouse for Windows and motion controllers for UWP. Having both in the MixedRealityInputSystemProfile spawns both on UWP. If I don't add the mouse I have nothing on Windows Standalone. This leads me to the conclusion that I have to create multiple profiles. But the MixedRealityToolkit only references a single one. Does that mean I have to additively load a different Toolkit with it's configuration for any platform configuration I want?
The DefaultMixedRealityInputSystemProfile already contains a lot of inputs, which makes me think it should be capable of doing that, but it looks like it does so to a certain degree and then fails.
Thinking further about this:
What if I want an UWP app, but for MR Portal only, or for UWP Standalone only. What about Oculus Go (Android) and Android mobile? The differentiation would be using the Oculus SDK under Android. Using it under windows would result in the Rift being used I guess.
Where do I branch off what?
I believe you can specify which input providers you want on different platforms. For example, if you want a MouseProvider in Windows only, the you can specify the Mouse Input Data Provider to run only on Windows via the “supported platforms” field of the mouse data provider.
Similarly you can enable the motion controllers using same technique.
While there are not yet ways to specify completely different configurations for different platforms, it is possible to solve your specific case of input by configuring the input data providers.

Xamarin.Forms + Custom Renderers vs. Xamarin.iOS/Xamarin.Android

I recently started using Xamarin.Forms for a project. Like the documentation mentions, it's great for prototyping. However, I'm really starting to notice limitations of the shared concepts for UI design. In particular, the inability to set custom button content (such as an image) is aggravating. I'm sure there will be several instances where I'll want to change how controls work.
The way I see it, there are two routes I could take. One, continue using Xamarin.Forms and make use of custom renderers. Considering I would still like my UI code to be shared, but also customized from the basic Xamarin.Forms controls, I'm leaning towards this option. Two, use the native Xamarin projects (Xamarin.iOS, Xamarin.Android). This would give me full control over the UI for each platform, but it would also mean more code to maintain.
Like I mentioned, I'm currently favoring the option to use custom renderers with Xamarin.Forms. Could I get some insight from those who have used one or (preferably) both options?
I've mainly used Xamarin.Forms. For the right kinds of apps (ones that are, well, "Forms"-like), it works pretty well.
Writing custom renderers isn't that hard, but the documentation is, unfortunately, not that great. Depending on what you're doing, it can be a bit tricky at times translating between the native control and the Forms layout engine. However once you get the hang of it, it makes sense, and now that the code is open source, you can peek inside to see how the "built-in" controls work.
There are various extensions that add more controls. Some are free and open source, like XLabs.Forms. So the control you need might be out there already.
You can use mechanisms like TapGestureRecognizer to turn an Image or a Label into a button, so just because the built-in Forms Button is really, really lacking in customizability, you can sometimes find other ways to get the same effect and still stay within pure Xamarin.Forms.
Hope that helps!
XamarinForms is good for sample application who don't need to use a lot of specificity of the device.
For complex applications, I advise you to start on Xamarin Ios and Android.
It will take more time to take charge but you will see it is much more permissive

Xamarin.Forms or Xamarin.Android/Xamarin.IOS

I am new to Xamarin and not sure if chose Xamarin.Forms to create a application for ios and android platform has a problem or not.
The application has some features below:
The application will be able to running some code in background without launching application by user.
The application can be launched by a href link or a notification.
The application is able to launch a builtin Camera application, and receive picture data from Camera application.
Thanks,
Bo
The features you are mentioning can be done with both. Actually, anything you can do on Xamarin.iOS and Xamarin.Android can be done with Forms. Because Forms is only an abstraction layer for the UI which is installed by a NuGet package.
Now, having that said when to use Forms or when to use iOS/Android? It is mostly about UI. Are you going to do some advanced or platform specific stuff is is easier to implement that with the platform specific project.
If you UI will be the same in both platforms and mostly consists of some lists and input fields, then that is a very good candidate for a Forms project.
Notice how I said it is easier to do in the platform specific projects. Again here, you can do anything in Forms as well by the means of Custom Renderers, it is just a bit harder to do.
Ideally try it out yourself and see what suits you best.
In regard with your need to execute code in the background. This will be tricky and is very dependent on the platform that you're on. You will definitely have to write platform specific code for that for which you can use the DependencyService to abstract it to your shared code.
However like AlancLui mentioned executing code in the background isn't something that is easy to do on mobile. On iOS it is restricted to accessing location data or playing music, but still your app needs to be running (in the background). Android has something called Services for this, which makes it a bit easier.

Share Code Between 2 Projects in Android Studio

I have 2 apps, one for the clients and one for the managers. They are based on similar code (Classes, Layouts, Activities).
How do I "share" those files between the 2 apps? So if I change a shared class or a layout, the change would be visible in both apps. (So I make only ONE change, and not have to make two).
I work on Android Studio.
Thank you.
Here is an excellent discussion about sharing code: StackOverFlow #24592027 I'm doing a pair of apps for Wear and Phone products and the Android docs recommend to build both in the same project file as separate modules. Based on the comments in the link, I created a third Module called 'sharedcode' that I can then link between the Wear and Phone apps. This give me a common shared code module. I think the point is that your two apps will also need to be combined into a single project. Each app gets its own compilation target, but they then both share the same code.
Then go into the dependency settings (File | Project Structure; tab to Dependencies) and set each app to depend on the SharedCode module. Good luck.

Is it possible to migrate a MonoCross application incrementally to MvvmCross?

The team I'm on created a cross-platform application that runs on iOS, Android, and Windows Mobile that was created using Xamarin's tools and MonoCross. We're looking at MvvmCross as a possible MonoCross replacement but don't want to write the application from scratch.
Does anyone have experience with or thoughts on migrating a Xamarin/MonoCross cross-platform application to Xamarin/MvvmCross? Is it possible for the two frameworks to coexist in the same app (the ideal solution would have us migrate the app one screen at a time).
Thanks in advance.
Following Stuart's advice below I confirmed that it is possible to integrate MvvmCross into an existing MonoCross application.
In the original code a selection on View 1 initiates a call to Controller 2 using MonoCross URI navigation. Controller 2 displays View 2, passing it the data from Model 2.
Following the example in this video I created an MvvmCross View and ViewModel. A selection on View 1 still navigates to Controller 2 but Controller 2 now displays the new MvvmCross View 2. View 2 is data bound to ViewModel 2 which takes over Controller 2's functions of getting the Model data.
I don't know of anyone who's done this recently, but I originally ported several of the MonoCross samples over when I first created MvvmCross. The overall idea of one page to one "ViewModel" stays the same, although the mvvm binding offers more continuous view-viewmodel interactions than the more discrete Controller-Action model.
At a practical level:
MvvmCross itself is very modular and can be used in "CrossLight" mode where it simply provides data-binding and plugins - see CrossLight in http://mvvmcross.wordpress.com/. You might be able to use this for migrating pages one-by-one
MonoCross isn't really very interface/IoC based - so you may find that your resulting MvvmCross migration would also not be interface based either
MonoCross apps tend to use file-linking and #defines rather than PCLs - so you may find it easier to not use PCLs in MvvmCross
I suspect the best option for this migration is to let your team experiment - they already have lots of knowledge about your app and about what they do and don't need and what benefits they do and don't get from a framework.

Resources