I am new to IOS 5 and I am interested in creating a flashcard app. My question is would it be ideal to make the make the text dynamic or use multiple images. The app would have over 200 words.
I have created the flash card page but now I need to determine which is the best step.
I would begin with a main menu that gives you a choice between creating a new "group" of cards and loading a previously created group. The card itself should be easy: Title, body, backside text. These cards can be saved in groups depending on their subject (e.x. Biology or Vocabulary for iPhones) and can then be accessed and flipped through by choosing the group. Use a modalview animation to flip the card over, it is probably the easiest.
Related
I am building a flutter application for a donation Kiosk, that would be deployed on tablets that connect to card readers.
I would like the home screen presented to users to contain a custom animation that can be loaded from a disk file (or downloaded) so that we could develop these custom animations for each NGO with ought building separate apps for each case.
The animation should be dynamic, meaning it should be able to take some parameters from the flutter app (ex: number of donations from the last 24h) and change the layout slightly (ex: show a number of trees based on that number).
I found some animation libraries but all of them would mean coding them inside the app, which is not the best scenario for us.
Is this possible? Can you help me by pointing in the right direction :)
Thank you!
How do you setup in your application to show little bubbles with text and block the rest of the screen from being used and only allow a small section / button to be pressed. I am wanting to create a walkthrough to show users how to use the application and where to find things within the application when it is opened for the first time.
I would like to dim the rest of the application except for the part I want them to click on. Is there a framework already with these features?
There's no frameworks that provide this functionality, as far as I know.
One way you could do this though is to have a set of overlay images which you overlay over the whole screen the first time the user goes to that screen. To determine if the user has already been to a screen, I suggest you look at NSUserDefaults. To create the overlay images, I'd make the image the full size of the screen (i.e. 460x320 if you are showing the status bar) and then have transparent sections where you want to "see through" to the element below. Add a gesture recogniser to the overlaid image view to detect a tap and then hide the image and set the flag in NSUserDefaults to make it not happen the next time the user goes to that screen.
If you don't get a better answer, you could look at MAAttachedWindow on the page at this link. It's written for Cocoa, not Cocoa Touch, so you would have to convert it. I am considering doing this myself. You might find it to be worth the trouble, but I haven't looked at every detail, yet, so I couldn't say for sure. There are only tow files that are involved (.m and .h).
I have a banner Advert view (could be an iAd or another type) and It loads an advert.
Now after it has loaded, I might want to move it offscreen (for example when I load a complex UI, I dont want to confuse the user, so I hide the ad).
My question is, will the advert know its offscreen? I.e. Will it stop updating its CPM and adjust advertising revenues accordingly, or will I be violating some kind of terms of service by pretending I am showing an advert when really its hidden?
The iAd ADBannerView will detect that it is not visible, so you can assume it will take appropriate action. There is no way to make a categorical statement about any generic advertising program.
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.