I am trying to convert a mid-size application to use MvvmCross that is already developed using Xamarin for both iOS and Android, but using normal techniques. Is it possible to mix MvvmCross techniques with normal style viewcontrollers and activities such that I can take my time slowing migrating screen by screen over to MvvmCross? At my current rate, it might take me a few weeks to convert the entire app over to MvvmCross and I would prefer it not to be an all or nothing procedure. My boss may not be willing to wait until I am completely finished so having some of it done before I switch over to working on enhancements would help later when I get more time to finish the conversion. Therefore, any tips you can think of for a slow migration screen by screen to MvvmCross would be helpful.
Is it possible to mix MvvmCross techniques with normal style viewcontrollers and activities such that I can take my time slowing migrating screen by screen over to MvvmCross?
Yes, you can easily mix and match 'code-behind' with MvvmCross.
For example, see projects like https://github.com/slodge/eh which uses a Storyboard with MvvmCross data-binding.
Therefore, any tips you can think of for a slow migration screen by screen to MvvmCross would be helpful.
Sorry - I don't personally think this second half is a good format of question for StackOverflow - it's just too general and non-specific. Maybe better to come back and ask specific individual questions when you hit specific issues or where you have specific problems with individual viewcontrollers.
Related
Is this possible? I would love to create multiple view controllers for each apple device. I know I could go in and add constraints to make all my labels and buttons line up properly, but after about 4 hours of messing with constraints and watching tutorials, I just can't get it right! Is there any possible way to just create multiple view controllers for each device?
You can, and I have done it before, but I wouldn't recommend it. I did that when AutoLayout was introduced and it all seemed too hard. I returned to AutoLayout when Apple introduced size classes. They make life much easier to have very different constraints for different devices. They also handle things like an iPhone 6 Plus being pretty much as big as an iPad mini.
You could probably spend a lot of time hacking away at making a work around for not being able to use auto-layout but you would definitely end up spending more time in the long run.
I struggled a lot with auto-layout when I started (and still wouldn't say i'm an expert) but after spending some time reading the millions of different tutorials I found it much easier.
It's difficult to recommend different sources for training material like this because everyone has a different preferred style. It's easy to recommend the official Apple docs (Auto Layout: https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/AutolayoutPG/index.html) but they can be so verbose that frankly, you end up getting bored and/or daunted so give up. Some people love youtube videos and some love blogs.
It's up to you to find a guide that helps but if you come back on Stack overflow with clearly explained, small and simple examples of UI elements that you are trying to manage with auto layout then people might try and explain what approach you should take and these instructions will come in different formats.
I have been making the native iPhone app and I have never used a xib, I mainly used to make the application in run time based, but know with the introduction of Main Story Board. I just want to know which one will be easier for using run time based which I mainly used to or start using story board.
Both have its own advantage and Storyboard has more options and ease when used in the right way (that is why it is introduced!).
By using storyboard
You can avoid so many line of code for page navigation and all
Complete picture of project is visible
By xib
Used a lot and hence more easy
Independent,so can be worked better
For working as a team xib is preferrable since the conflicts can be less if each team member working in seperate files
MY SOLUTION
Since it is possible to use both in same project. I use both in my projects. To take the both advantages according to my requirement.
You'll probably want to use a Storyboard(s) in the long run. However, there are pros and cons:
Pros
You can see your whole project
You avoid a whole lot of nasty code
You can visually 'hook' stuff together
Cons
Only available >iOS 5.0 <<<<Huge!
In my personal experience, I usually use Storyboards - the percentage of devices running < iOS 5 is actually quite low.
I've done a bit of iPhone development (3 apps in the appstore currently) but the interface has been pretty plain. I've used the stock components for the most part (UITableViewController, etc.) with a little bit of customization, but for the most part everything looks pretty generic. I'd like to get started developing apps with a richer user interface, but haven't found any good resources to get me started.
What resources have you all come across that outline how to create more advanced iOS interfaces (both iPhone and iPad)? Books? Blog entries? Just looking at the apps I have installed right now, some of the interfaces I've been very impressed with are the ESPN Score Center, XFINITY TV, Facebook, etc.
What about 3rd party interface component libraries? Are there any you recommend that provide more advanced interface components than those in the stock iOS library?
I'd love to take a look at any resources that you recommend for getting started.
I love Ray Wenderlich's tutorials. He's got one on Core Graphics which allows you to draw your own Table Views with headers, buttons, and bezier-curved footers!
Here's a little secret that often gets overlooked: a lot of the cool UI elements you see are stock Apple elements that have been customised to the brink of no return.
The main reason for this is Apple have put a lot of time and effort into making components that just plain work. A UIScrollView, for example, has had many more combined hours of testing than any app you write could hope to achieve.
The trick is to know exactly how to customise elements. A UITabBar is a good example: I've seen several apps that use their own custom tab bars. The problem is, often they don't handle edge cases particularly well. You might have issues if somebody tries to hit two items at the same time (I've actually seen an app that used their own implementation of a tab-bar crash if you pressed two items at the same time).
But if you use Apple's UITabBarController and either subclass, categorise, or otherwise overload it to get the customisation you want, you get a lot of the low-level event handling stuff for free.
You would be amazed with what you can do with a UITableViewController, and you get things like view recycling for free (some of the apps I've worked on have things like independent cell resizing, customised animation of cells, horizontal implementations of a tableview, etc).
Not a particularly useful answer, I grant you, but the point I want to get across here is once you've designed your kick-ass UI step back and consider what can be achieved with the existing toolset before rolling your own. You'll thank me when you come to bug fixing!
I also like Three20. Until now I didn't use it in my projects, but I played with it. And there's some really cool stuff in it. ;-) I think that's one way to extend your standard User Interfaces.
Another really cool part is designing your own elements. I like this really. Because you then have in your App something nobody else has. :-D
I've started looking into using Opacity for Mac, it's a pretty neat desktop application where you can generate your own graphical elements (buttons, switches, icons, etc) and then automatically generate the CocoaTouch / Quartz2D classes and headers to drop in your app ... Some elements work best when they're natively drawn on the device, rather than stored/loaded as pngs, or whatever. Moreover, you get #2x Retina display support for free. While not an interface dress-up framework, the fact that it generates Quartz2D code for you makes this a real contender for anyone who's remotely graphically creative but short on complex 2D programming skills.
Speaking of beautiful interfaces, if you're looking for inspiration or actual graphical elements to put in your interface, I frequently get some great ideas at 365psd ... they actually provide the Photoshop documents to reproduce some eye dropping UI goods, for FREE. Some places may just give you a PNG, but this does little good if you want to scale it (#2x or iPad) or customize it to fit your needs. It's like open source for graphical UI design.
Are there any major advantages/disadvantages I should take into consideration when developing an app which and deciding whether to creates parts (styled menus, pages with content with complex layout etc.) in HTML/UIWebview or doing it all native?
I would like to hear people's experiences with this.
Personally, I find that I tend to dislike web apps that are (usually) disguised as iOS apps. I tend to notice a lot of inconsistencies between the UI of a web app and a 'native' app, and most of the time, it bothers me (my biggest pet peeve is tapping a button and seeing it highlight with a little translucent black box around it like a link). Now, I don't represent the major user demographic, which probably won't care, but that's my personal opinion.
In terms of programming, I've never written a web app before, but I assume that it's going to be slightly less structured than a native app just because writing HTML, Javascript, and CSS doesn't force you to assume a certain project structure, unlike iPhone apps that have distinct views, controllers, and the like. Depending on what you want to write, this might be liberating, but can also get tangled very quickly.
As middaparka said, you can also use a mixture of the two systems if you'd like. I mean, I'm assuming you're just as good a web developer as you are an iOS developer. If you are stronger in one suit than the other, then I say that you should lean towards heading in that direction. I'd much rather see an excellently written web app than a badly written native app, and vice versa.
I suspect the major advantages/disadvantages relate to the user experience - a "native" UIKit based user interface will feel a lot more natural than manipulating items within a web view. (It'll also mean you can use more "standard" components like navigation controllers, tab bars, etc.)
That said, there's no reason not to use a mix of the two, with the main UI being implemented via the various UIKit objects and the content being provided via a web view.
I would also add that the biggest issue I've found with hybrid frameworks is that you add another dependency to your app.
For example, take a big iOS update. If your chosen framework breaks, your app breaks and you won't be able to fix it until the framework is fixed.
Also, right now there are many frameworks and you have to pray that the one you chose isn't flushed down the toilet or drops support for one of your target platforms.
Another issue is that in a web based app/component you are missing out on platform specific technologies and frameworks like core data, GCD (or any other threading model - which in web you might have do with e.g. Ajax),uitableview with caching etc.
Should you hit a wall when it comes to performance or storage,then you have many more options in the native framework.
I have a friend who is a graphic designer & user experience designer who will be collaborating with me to develop an iPhone app. He does not have previous iPhone experience. What is the best way to work with him on developing the user interface, i.e. custom colors for UITableViews, UIButtons, etc? We've looked into Photoshop mock ups, but that depends on me (the developer) implementing what he drew in Photoshop, which might get tricky.
Most of the methods I've thought of have long turn around time, i.e. he uses Photoshop, sends me the image, I develop, send him a test build of the app, he doesn't like it, rinse, lather, repeat.
Do you think it's feasible to set him up with Interface Builder so he can modify XIB files? Potentially, he could build and run the app in the simulator...
Does anyone have experience doing this? Any suggestions?
Thanks much,
-dan
This goes for a developer or designer. The best way in my opinion is to mock up designs in photoshop, debate on what is good and what is bad, then send the final mock ups to the developer.
The reason you want to do it this way is because your designer can't do everything he wants to do by simply using the IB. You need to allow your designer to express his creative freedom without the burdeon of figuring out how to use a piece of software correctly.
You can find plenty of templates of iPhone and iPad components on the web. Having those components will make it very simple for your friend to put together concepts. It will also keep things consistent so you can have an easier time implementing them.
A Great Collection of iPad Resources
iPhone Materials
One suggestion is to start with the elements that do not need graphic design but you know they will be there, this will be things like table views, tab bars, any UI element provided by UIKit or even custom UI elements that you make...I would say you will probably have most of your app made by this approach and will look VERY plain...once you have that basis you should be able to work with the graphic designer and identify where and what he needs to make, it should also be pretty easy for you to integrate it since it will probably be mostly images or textures, things like animations and such will have to be handled by you anyway...just a suggestion, hope its helpful
Omnigraffle is your best bet for quickly mocking out UIs. It produces nearly photorealistic mockups. It's easy for non-artist to use but can also utilize imported images of arbitrary complexity if he needs to do something fancy.
If you want my advice, keep the graphic designers away from the app until it is fully functional logically. They should only be brought in at the end of the process to tweak the UI.
They cause train wrecks if they come into the process early. Everybody in that field has been trained first and foremost to create visuals that attract attention. In an UI, that always translates into flashy, non-standard elements that turn into annoyance with repeated use. A good UI is essentially invisible to the user. Ideally, they should notice it only because they notice that they don't notice it. (It's all very Zen.)
People trained to attract attention in the blizzard of competing images of a media saturated world don't make invisible interfaces. They make "in your face" and "look at me!" interfaces that get old in a hurry.
Don't get me wrong: a good graphics person can really enhance an interface by the skillful and subtle use of proportion and color. Unfortunately finding a good UI graphics person is a challenge. Be prepared for fights over what works transparently versus what looks cool and draws attention the first time you see it.