1) I want to create a List by touch and dragging icons from a Master List.
2) Also have the ability to Delete items in this newly created List or Rearrange their order.
Is there some code sample one could look at or possible design pointers on cleanly accomplish this functionality.
I realize UITableView could accomplish this. But doing it visually in a single screenful is intuitive as it maintains the overall context of the task at hand.
Thanks
None of the API UI classes will let you do this. Both tableviews and scrollviews want the entire screen. You're going to have to write a lot of stuff from scratch.
I think you will find that a dual list design is a poor interface choice. You really don't have room on an iPhone screen to display and manipulate two list within the same view. Remember as well that you won't be able to see all of both list if they run off the screen (which is likely.)
"Intuitive" is just marketing speak for "familiar". There is nothing intuitive about a nonstandard interface. Since iPhone users don't routinely drag items between list it will not be readily apparent to them how to work the interface. You will most likely be better off with a single master table in which users can check individual cells to be added to a sub list. This is a common interface on the iPhone and therefore more "intuitive".
Before spending a lot of time on this, I suggest you do a mockup that will display on the device itself. You can simply draw mock interface in a graphics program and then display it as an image in an imageview. This will let you test if you can display enough information in dual list to be useful and whether you can hit elements in both list reliably.
Related
This is going to be a bit difficult to explain. I'm usually fine with code on the micro level, but need some guidance on the macro end. Anything would help.
I'm trying to basically create a notecard application, where the user is presented with a screen with a stack of flashcards. There are multiple subjects, each managed by a different .plist. To switch between subject areas, you swipe left and right. I don't know how to most efficiently achieve this using storyboards, which is my primary issue. Could you do this using one view, or do I have to create a different view for every stack of flashcards and create a transition between them?
Thank you very much, in advance.
If you are looking to switch between different views by either swiping left of right, the most logical choice would be to use a UIScrollView with paging enabled. You could then initialize an NSArray and have it store the names of your different PList files and use it to manage your data between views. Obviously this is just one of many solutions to this problems, but when you talk about wanting a swiping action to switch, UIScrollViews would be the iOS default way of doing it.
Here is a tutorial on how to use UIScrollViews with paging:
http://www.iosdevnotes.com/2011/03/uiscrollview-paging/
Hope that helps!
I'd like to display two windows on screen with scrolling text in them e.g. top window will have one bible translation while the bottom view would have another.
Ideally, I'd like them to stay in sync so they're both showing the same point in their respective translations (i.e. switch to John Ch1 in top view, bottom view follows and does same). But for now I'm just curious how to get these into two seperate viewable windows.
Any ideas?
In all honesty, I dont think you have the screen space to do this for the iPhone in such a way that is visually comfortable for the user.
That aside, the best method would depend on how the rest of your app is built. You can create a view that contains two UITextViews in it, each taking up roughly half the screen. You should be able to scroll one as a response to the other scrolling, though I haven't done this, so I cannot tell you how to do it exactly.
Another option that you have is to use a main UITextView, and then a second UIModalView that is overlaid above it. It all depends on the app structure.
Just to note, unless you have specific markers for points of translation, it would be very hard to have them sync up in that way. You could try to match line numbers, or something like that, but due to languages being so different, one might take 3 lines, and a translation might take 4 to say the same thing.
This is a fairly basic question, so you should perhaps revisit the iOS Application Programming Guide, but in a nutshell, you'd have two UITextView elements inside a view in your application, and you can synchronize between them using the built in setter method
- (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated
You have two needs here:
(1) You need to create a data model that can hold the translations and link each chapter and verse in each translation to the chapter and verse in all the other translations. For that, I would suggest learning Core Data. Be prepared to spend some time learning it.
(2) You need to display the translations. For this I would suggest you use two UITextViews in the same containing view. However, as Karoly S noted, there really isn't room on an iphone screen for two text views. I would recommend using two views connect by a flip transition which will allow you to have one translation on a full screen and then flip over to the other translation. The user could flip rapidly back and forth to compare.
When I started with IPhone development I preferred using Interface builder for creating views in my application. With time I considered the option of creating the application via code which I really feel comfortable working with.
Now, when I know both ways to create my user interface, I have doubts which way to follow. I keep thinking where to use IB and where to use code. How can I figure out before starting with my application, which way should I create my UI?
There are a number of factors that can influence your choice. It can come down to personal taste, but there are some advantages to using Interface Builder.
The first thing to recognize is that UI design is inherently a visual task. Interface Builder can allow you to create and modify a UI much faster than you can in code. Rather than endlessly tweaking CGRect values in code, then recompiling, testing, and repeating this process, you can instead get direct visual feedback about your changes. This means you can refine and polish the UI much more efficiently, and even test out radically different layouts without too much time or effort.
Another important point is that if you can create and layout a control in Interface Builder, that means there is less code in your view controller. Less code is always a good thing (less bugs, easier to maintain, ...).
So I believe you should try to define as much of the layout and properties in Interface Builder as you can. This can be hard for people who prefer "full control" over things. Many years ago, visual GUI editors were renowned for doing the wrong thing, and developers often shunned their use over doing everything by hand. But Interface Builder is pretty good at what it does, and you can easily dive into code when you need to.
The situations where you would create controls purely in code are when you need to dynamically create a number of objects, for example thumbnail buttons for a photo gallery, or if you have custom layout requirements.
For example, if you have a label whose height is dynamic at runtime, and you want to layout a bunch of controls underneath it (taking its height into consideration), that can only be done in code (UPDATE: iOS 6's Auto-layout can do this now). You can either create and layout everything in code, or you can still create the controls using Interface Builder and just give them arbitrary positions in the XIB which are modified when you lay them out in code. It's not uncommon to see this in some of my XIBs:
The buttons along the top can be created and layed out fully in IB, but the image views below need their images and positions to be calculated at runtime. So we just give them arbitrary positions in the XIB. Some might find this ugly, but it saves time and effort on writing code to create the image views and set up their properties. Again, less code is a good thing.
Other times you may want to use code is setting certain explicit properties. Let's say you have an image view which needs to receive touch events because it has some gesture recognizers added to it. You need to set the "User Interaction Enabled" property to TRUE. It can be better to do this in code because the requirement is more visible and you can leave appropriate comments as to why you are setting the property. It's also harder to 'lose' the setting like you can in interface builder if you need to delete and recreate a bunch of views.
I think for many applications that use the stock UI, Interface Builder is a great tool to rapidly get things up and linked with the underlying code. Also, it really stresses the paradigm of the View being separated from the Controller as you really can't push code into places where it shouldn't be.
That being said, I use it less and less the more I learn about how to rapidly code interfaces due to the fact that they may need to be more flexible or need a variable number of UI elements based on the Model behind it.
Use interface builder as per your requirement. It's depend on you that how you manage things. See creating a custom cell using interface builder is much easier to update at a later stage while using code you have to do a lot of changes if layout changes. Also you can visualize the view before running the actual app but in code you cannot you just have to assume.There are both prons and cons of both things.
Does a library exist to work with trees for iPhone ?
Or if you don't want to deal with CoreFoundation objects, SO user Quinn Taylor puts a ton of time into the CHDataStructures framework, which has trees, queues, stacks, etc and that works on Mac and iPhone: http://cocoaheads.byu.edu/code/CHDataStructures
It's a really solid framework and I highly recommend it.
The default way to simulate tree browsing would be with a UINavigationView where the views contain UITableViews containing all the leaf elements of that branch. You may want to look there first in the Apple Documentation. It is quite simple to implement.
If you are intending for something like a Windows Tree View control then I am not aware of any. General concensus suggests that a TV control does not really fit with the iPhone UI paradigm. If you find yourself needing this then maybe you need to rethink your UI design.
I did half an attempt at a tree view, implementing a tableview and using the rowHeightForCellAtIndexPath to return a very small number (0 or 1) for collapsed rows. I had to maintain the tree state in an offline structure (NSDictionary) and render from that. Each cell had to be custom rendered completely. In the end, it was much better to implement it as a Navigation View as this fitted with the iPhone UI and the way you expect iPhone applications to behave much better.
If you are talking about a tree data structure, as opposed to a user interface control, you can use CFTree. A quick summary of how CFTree works is on CocoaDev.com.
I'm making an application for the iPhone. Essentially it'll be a guide of sorts, and all the generated information will be in one long window. Each block of information can have a 'link' in it to generate another block of connected information (for example a block about Wallace could link to a block about Gromit) that would appear at the top.
For example, at the start 1 block of data:
Wallace: Owner of Gromit
would become 2 blocks (on clicking Gromit):
Gromit: Wallace's Dog
Wallace:Owner of Gromit
Each block would also have the ability to be added to favorites list by clicking an icon. The text would need to be laid out with HTML and each block may be of a different length. A search on a different could also add a block to the top.
I'm OK with objects in 'easy' languages like PHP, but am basically new to iPhone and Cocoa, and I want to start off with the right approach here. A Table and cells looks like the correct approach, but is there any advantage of doing it as a long list (like I might do on a web version) or are there any restrictions in the way cells can hold/layout information that will cause me trouble down the line.
I believe this approach is popular for dictionaries.
I'm committed to doing it the way with a single scroll for a couple of reasons. The main one is that I want the user to be able to scroll instantly back to entries they've looked at before. i.e. the single view essentially represents a history of the data they've looked at. (if it's a lot stuff can drop off the end). Each entry will be very short but there will be a lot in total. So if the user has looked at
Wallace
Gromit
The Wrong Trousers
Cheese
Penguin
And they are not looking at Wallace, a quick half second scroll takes them back to 'penguin'.
Hierarchy is the way to go on the iPhone.
Remember that the iPhone has a small screen and that users can only see a very small amount of information at anyone time. (One interface expert compared it to driving while peering down a two inch pipe with one eye.) Users can easily get lost scrolling up and down a very long list even if it has index. (That's assuming your information can be easily indexed in a form that users will instantly recognize.) It's usually easier for users to click through several views with the data in each view getting more and more specific with each level. In addition, so many apps use this hierarchal system that your users will be used to it and expect it.
System wise, its easier for the iPhone to display just one level of hierarchy at a time so your app feels more responsive. The hardware doesn't to maintain all the data in memory but just the data it needs to immediately display.
If I understand you data model correctly, you would be best off with a hierarchy of two tables and a detail view. The first table would have an list of letters A-Z. The second table would be list of all records starting with that letter. The third would be a detail view showing links to that record. So, to see the example in the OP, a user would select W-->Wallace-->(Detail) Gromit.
Edit01:
I think you should do a test scroll of either a very long web page or UIScrollView and see how it affects performance and usability. I would caution you that layouts that seem perfectly usable and fast on laptop or desktop hardware become unusable and slow on mobiles with their weaker processors and much smaller screens. It's much more difficult to do " a quick half second scroll" back to a specific point on a long page on a mobile than on a larger screen.
You do have the option of creating a outline-like table view that inserts new indented cells as needed. I still think hierarchy is the quickest and most usable layout on a mobile.