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.
Related
I'm new to programming apps, trying to realize a project for iOs using xCode and swift.
As far as I've learned most people seem to work with the storyboard feature, but I've come across people that suggest to deactivate the storyboard and work with code only.
I'd like to know your opinion on what method fits my needs best for the intended project. As I am just getting started, I'd like to stick with the appropriate method right away for I'm probably going to invest a lot of time.
This is about what the app is going to look like:
myApp Layout
Now this is what it' basically supposed to do:
The "settings"-button (blue area, top left) is going to take you to a different view to set preferences. The "search"-button (blue area, top right) is going to change the title into a search field.
You can browse through 3 categories. Each of them contains a couple of questions. Those are stored in a database and are supposed to be displayed list style within the red area. The order of the questions is going to depend on the users preferences.
Clicking any of the questions is going to take you to another view that displays the answer. When viewing the answer the "settings"-button (blue area, top left) is changing to a "go back"-button.
Now as far as I've learned the blue area might be realized with a navigation controller, navigation bar.
The white section works pretty much like a toolbar. However I've read it's close to impossible to move the standard toolbar from the bottom to the top.
I've seen tutorials of people realizing this type of layout with (to me) complex code but without using the storyboard. Am I wasting time on figuring out how to manipulate storyboard objects? Coming from coding and programming websites the project looks so unbelievably simple. Is a project like this in fact rather complex to do as an app?
In any big project you will have to use all approaches, it is all about experience. For example, I am using StoryBoards to make 95% of my UIViewControllers elements, using XIB for static screens like error messages, some loadings etc. and using code to append some gradient views, shadows etc. It is possible that in future I will be doing all in a different way. But if you are a beginner - better use Storyboard, it makes getting into all of it much easier, understanding UIKit and iOS development overall.
can i show table view in this way
specification
000001,s able to hide all.
000003 is able to hide from 3 to 14..
000011 able to hide only 12,13 and 14..
Thanks,
Shyam
Have a look at the indentationlevelforrowatindexpath method of UITableViewDelegate, as mentioned here -- it gives you the option of indenting different table cells with different amounts.
However, you need to ask yourself if the UI you propose is appropriate. Apple in their Human Interface Guidelines say that you should avoid presenting a tree-like control with too many levels in it, because it doesn't present well on a limited display space. In this case there's often a better mobile UI design available, e.g. break things up into different levels in a UINavigationController structure.
On the iPad obviously you have more screen real estate to play with, but it's still a point worth taking seriously.
I am pretty new to iPhone development and currently working on an application which includes a view that performs a simple numerical calculation. In particular, the user enters 3 or 4 values into text fields and the view displays the result. Something along the lines of http://www.moneychimp.com/calculator/compound_interest_calculator.htm
What is the nicest way to achieve this? I am currently using simple UITextFields and a UILabel for the result but it doesn't look nice or "native-like". What UI object would be best to use?
Thank you!
It's entirely up to you. You're using the right classes for actual input- it comes down to how you choose to style those classes. I'd suggest looking at the documentation for UIView and CALayer (youView.layer, and include QuartzCore framework in your project).
A good start might be to choose a color scheme, a background for your app, and the look and feel you're shooting for- this will inform your styling. Try looking for apps that you think are elegant and attractive, and boil down what they do and what you like about them.
I'd say;
use a grouped table style (with the white tables with round corners on a blueish striped background)
embed settings values directly in the cell (aligned to the right) as much as possible
you can show a relevant keyboard (text, numbers) or picker view to let the user pick values, directly when they tap the cell. Use sliders and switches where relevant.
You may want to take a look at http://www.inappsettingskit.com/, we are currently investigating it for the same purpose and it seems to do the job
You can use either a UISlider or a UIPickerView if some of your values have limits.
You can use UISwitch for toggles.
You can also switch the default keyboard for your textfields to be numeric.
Other than that you seem to be on the right track.
Also, sometimes putting a view inside a scrollview makes things seem cooler even if its only one page. The auto bounce on scrollviews is kind of cool.
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.
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.