I am busy with a score overview and I was wondering what is the best way to do it.
My first thought is that is would be an UITableView because of all the functionality it already got.
But because of all the functionality it also has it limitation when you want to change the look.
I was wondering what is a better way:
An custom UITableViewCell what you design your way and that with an plain tableview
An UIScrollview where every score is an UIView
I think the first one is easier and probably better memory solution but the second one is better if you look at customization.
So I was wondering what you think and if you know some good reading about this.
The additional memory / cpu consumption is probably not noticeable, unless you've got more than 100 results or so.
Therefore I'd use a scroll view with UIViews, it's just so much simpler to implement. Additionally it's much easier to add custom behaviour later if you need something fancy.
Related
I'm looking to implement a UIPickerView where the user presses spin and the picker selects a random option. I'm curious if there are any ways to make the spinning effect last longer?
The only way I've really thought of, or seen, is increasing the number of items in the component simulating that the picker is really "spinning". Is this my only option?
Thanks.
You may test the actual performance with the huge number UIPickerView first, or actually build a slot machine component like this one:
iPadSlotMachine
With the stock iOS controller, no, I do not believe this is really possible.
Your idea might work, but will probably suffer from some graphical glitches as you add/remove elements during animation. Definitely worth trying though, to see if it is good enough for your needs.
Unfortunately, I think you'd have to write your own custom controller to really get the "slot machine" effect you're after properly. I would suggest google around and checking github, etc to see if anyone has written an open source one.
I released the first beta version of my iPhone app on TestFlightApp today. Everything is going really well until I notice that the responsiveness of the application is pretty cruddy. Certainly doesn't have a "nice" native feel that I'm going for.
I've been particularly fastidious concerning my memory allocation/deallocation, so I don't think this is the issue. Basically, I don't know where to turn to next in order to improve the performance of my app.
Here's where I think some of my slowdown can be attributed to:
Using UIAppearance to customize the looks of most (if not all) UI elements. I use a brand new font, lots of CAGradientLayers, and lots of edits to CALayer in order to draw nice Shadows.
Grouped UITableViewCells that display pictures of a map and itemized lists.
UITableViewCells whose layouts are updated every time I call layoutSubviews.
UITableViewCells with customized heights. For each call of heightForRowAtIndexPath, I need to reconstruct and re-layout the view, returning the exact height each time.
Because I programmatically created views, controllers with longer viewDidLoad calls tend to load slower. What code can I offset in the init call?
Does anyone have any hints or tips for dealing with these problems? Or perhaps people have stories about how they dealt with a slowdown in performance when they released their first app?
My answer won't address all of your points, but here are a couple:
1) Make sure you are using Shadow Paths. Paths are much, much more performant.
2) Are you using transparency or corner rounding? If so, try and reduce transparency as much as possible and do not round corners using CALayer cornerRadius. Instead, use a clipping mask in the drawRect of the view that needs to be rounded.
4) Perhaps you can cache the height in an array and not have to repeat the calculation, each and every time. This may/may not scale well depending on the potential number of items, but may be acceptable depending on the use case.
5) Are there views you can reuse? For example, when I have a custom selection view on a UITableViewCell, I only create a single instance held by the controller and reference it in all the cells.
Did you run Instruments (or other profiling methodology) to determine where you app is spending most of it's time. It would be a good idea to do this before optimizing the wrong thing.
I want to decide if it is better to use XIBs or to designs my views completely using code.
So far I have read that when you design your views on interface builder they are pre-built, so even if they use more memory the user feels everything is faster.
People say doing everything using code is harder but I find it to be just as easy, so I want to know if anyone has experienced some real speed gains when using nibs.
What have been your experiences, advice, etc?
Thanks!
You should be able to do both -- there are times when building a view programmatically is better/easier, and times when using a .xib is better/easier. Even if you only ever do things one way, you'll run into code that does it the other, and you'll need to be able to deal with that.
If you don't know how to use IB, then building your views in code is certainly easier. That is why you should learn to use IB. Once you understand IB, it's way, way faster to put together most of the view-based UI your app will likely need. IB helps you line things up, center objects, align base lines, connect controls to their targets and actions, etc. I think it's safe to say that everyone who uses IB effectively experiences "real speed gains when using nibs."
You should know how to use both. Performance differences between the two are negligible and should not be the reason that you choose one or the other.
Many people who are new to iOS development have the misconception that nibs (.xib files) are inferior to programmatically creating your UI and that if you use IB you're not a good iOS developer. That view is 100% wrong. IB is created by Apple and in use by Apple's developers to create their own Mac OS X and iOS apps. If IB (as a tool) is good enough to be used by some of the best developers in the world, it's probably good enough for most of us.
In practice I have found that a combination of the two usually fits the bill.
In my own apps I find that .xibs are great for laying out the basics of your views quickly and they allow you to iterate very quickly while giving you a preview of what your view will look like. It's also much easier to use auto layout in a .xib file.
Then when you need to do more advanced things like add fancy animations or move views around that is what IBOutlets are for. Anything that you put into a nib can be referenced through an IBOutlet. This allows you do then programmatically make your view come to life.
Lastly, you should fully understand what a nib (.xib) is doing automagically for you. You should understand what happens when a .xib's objects are unfrozen. There are many resources on the internet to understand .xib files better.
Also, learn how to use .xibs in an encapsulated way. For example, .xibs are crazy useful for things like prototype cells and they allow you to keep your code base modular (much more so than storyboards). Also, you will require less UI code in your view controllers.
Lastly, I always say that people should think of IB/.xibs like jQuery. It's going to save you a lot of time but the best developers still know how to do everything in javascript if they have to.
Good luck and have fun!
TL;DR version
Performance is not a consideration when deciding to use .xibs or not.
Use .xibs because they give you a preview of the view you are creating and they allow you to quickly iterate
In practice most apps will use a combination of both. You will programmatically add animations or move views around but the .xibs will be a starting point
Understand fully what happens when the objects in a .xib are unfrozen
You'll be more productive but be sure you fully understand what is happening behind the scenes.
I would always use XIB files unless there was a reason not to. This allows your views to be maintained easily in the future.
Some reasons for creating the views programmatically might be:
A control needs to be resized,
repositioned or otherwise altered
depending on something else
Controls
need to be added or removed
dynamically
There may be more reasons but there are not too many.
If you programmatically create views when there is no need you make it a lot more difficult for other developers to try to figure out what the view will look like and to change it.
If you build your views programmatically, you have control over the loading of elements. e.g. you could use lazy loading, and load secondary buttons, subviews, etc. a fraction of a second after the more important elements, allowing the key parts of the UI to come up faster. You could even animate some elements into position.
If you use IB, you get guides as to proper element spacings and positioning, but you could always copy the coordinates from IB into code if you aren't changing the design that often.
For simple UI elements, you will end up with more lines of code to maintain if you create them programatically.
IB and NIBs do a lot to optimise loading/unloading of views, but it is largely oriented to minimising memory usage vs. perceived speed for the user. For example, lazy loading if anything might make the app UI slightly slower, but it should make memory usage lower. This in turn could make overall app performance better on a large application, and is very much encouraged, but it's difficult to define "performance" in a narrow way. It's also difficult to say when you should or should not use IB - there will be some times you're much better off doing it in code.
One often overlooked element to the IB or not debate is development speed, especially if you have multiple developers. On a larger team/project you'll probably have some developer(s) who specialise more in the infrastructure, business logic etc. of the app and some developer(s) who specialise more in the UI. In this case, use of IB will make it easier for them to work independently, which should make overall development more efficient.
I view IB as a core part of the development platform for iOS development. It's not the right solution in every situation but not knowing how to use IB will be a real limiting factor.
I've been using Xcode for a while and had a brief look at the interface builder when I first started but then went straight on to coding everything.
So far it's working OK but I just wondered if I'm missing something by not using the IB.
Is there any advantage to using the IB at all? I've even coded subviews and stuff without using the IB but I can't help thinking that it might be more advantageous to use it?
If not I'll keep on doing what I'm doing as it's working for me up to now :D
Thanks
If constructing everything in code is working for you, then great. Personally if it can be done in IB it's done in IB.
I'd be surprised if there's a best practice for this; everyone will have their opinion and preference.
I like to do UI related work in IB - if i'm dealing with presentational concerns I like to be in an environment that offers immediate visual feedback. It also cuts down the amount of boiler-plate code that you would have if constructing everything programmatically.
That said you can't do everything in IB. There are times you'll fall back on programatically constructing or laying out a view.
A little knowledge of both approaches goes a long way...
possible duplicate of: iphone app best practice - is using the IB a better way to design your app, or writing UI code on your own better?
at the end of the day its whatever you feel more comfortable doing. IB is horrible in my opinion, programming takes more effort - more thought. :)
I usually use IB, get immediate visual feedback and make the layout looks exactly easier. Only in one case that I have to give up with IB is performance with UITableView scrolling. In this case, the best solution I can find is to write code to draw everything in the cell using code. This makes the performance much better.
Generally, I recommend to use IB until you have some specific requirements like performance or you need to have really much control over the view
New projects always start off simple so people tend to gravitate toward IB naturally.
Personally I've found that as a view gets more dynamic and complex (and they always do), it makes sense to code it.
YMMV.
This is a question for iPhone development and I'm hopin someone can point me to the right direction on how i should go about implementing this.
I am trying to write a chat application that supports emoticons/smileys. Where the smiley/emoticon images are stored can be figured out later. I think few iphone applications out there are already doing this (i.e. skype + ebuddy(?)) but not sure what method they went for.
After searching around, there seems to be a few ways of doing this (i think):
bubble chat style which has been discussed before. UITableViewController with custom UITableViewCell. For emoticons, might have to do a whole bunch of calculations to determine where to stick a UIImageView for each emoticon.
Use UIWebView as the whole "window". Style it to look like bubble chat. Takes away any manual calculations on image smiley placements.
I have no idea what the performance is like for each of these two methods, how complex it can get etc, so any comments and guidance will help for sure. Cheers
If you use custom UITableViewCell, then I'd probably implement drawRect: instead of adding labels and images. One will probably take as long to implement as the other, but it will perform much better.
The UIWebView might be worth a short, although you will have to make sure that everything looks right there, too. Instead of using one big web page, I suggest simply throwing in a web view into each table view cell.
Personally I prefer the first approach, measuring and layout of text is not too complicated, but then I've never been the ultimate HTML guru.
I agree with #Eiko on making custom UITableViewCells, especially using drawRect instead of adding labels, images, etc.
If you used a UIWebView how would you handle updating it? A complete reload each time new text is sent? That seems like it will be a cause of issues. Once you get a long conversation reloading the entire UIWebView's contents will cause some flickering which isn't acceptable in my opinion. Also using a UIWebView would require you to have 2 complete copies of each conversation in memory. 1 as your backend data and 1 as the HTML. Where using a UITableView you have your backend data, and only enough of that will be duplicated that can fill 1 screen at a time.