Originally I had a different post, just wanted to redo it to clean it up.
This is more or less the layout I wanted to go with. Imagine the first imageview had dog pictures, the second one had cat pictures and the third one had rabbit pictures. three folders contain a group of three separate sets of pictures.
What is the best way to set it up so I can randomly swipe, lets say the first image view where it would only show pictures of dogs.
What I am asking is, is there a certain way to create the file structures or link the pictures to each image view?
I have the basics of the random (something with a 4 in it don't remember the method exactly) and the basics of swipe, just was looking for help with linking the photos and file structure.
Please let me know if this still doesn't make sense.
Thank you
EDIT
after messing with this this is where I am at:
with a very simple array basically
catsArray: [String] = ["catpic1","catpic2"......]
then I have it set up as
let randomIndex = Int(arc4random_uniform(UInt32(catArray.count)))
if (sender.direction == .Right)
{
self.catImageView.image = UIImage(named: catArray[randomIndex])
}
just me hacking things off the internet. now I am running into an issue. after a few swipes I get a null images or its just blank. Why is that?
now that I have some of this set up I am debating if I should just use parse for a server or if there is a better way.
thanks
Either approach will work. It's probably a good exercise to write both versions. You'd learn from it.
Your question is far too vague. Are you worried about memory? If so, you should not load the images into an array. Instead load the image names, and load each image as it is swiped on-screen. You might want to load the current image and the next image so it's already in memory and can be displayed without lag.
Are you talking about using a UIPageViewController? That's a good class for managing a set of pages that you can scroll through. There is a sample app from Apple called PhotoScroller that illustrates that technique, along with tiling the images so you can display large images and handle zooming and panning. (The app is written in Objective-C however.)
EDIT:
Your updates make your question a little clearer.
There are lots of ways to handle this. Here's 1.
Create 3 separate folders, one for cats, one for dogs, and one for rabbits. (in your app's documents directory, or in the bundle, if the images will be shipped with the app.)
Use NSFileManager to create 3 separate arrays of filenames. Take a look at the methods contentsOfDirectoryAtURL:includingPropertiesForKeys:options:error: and contentsOfDirectoryAtPath:error:. You should be able to make either of those work.
Then you'll need to scramble your arrays of filenames to create a randomized order. You can use one of the block-based sort methods where your block uses a random number to determine the sort order of each pair of objects.
Finally you'll need to implement the swipe to switch.
It sounds like you are beginner so this is a lot to work through. You should break the problem into pieces and tackle them one at a time.
Related
I have a TableViewController which is connected to a empty-"template" viewController. I would like to make each cell responsible for its own interface/design.
In other words: the viewController has all elements placed (like UIImage, UILabel, UIText, etc.) and each time when specific cell is selected the viewController starts to fill with specific images/resources. Moreover, it would be great if the resources will be taken from web or cloud (in order to not save everything in the application itself).
So, I imagine it somehow like this:
Flow sketch
The problem is that I deal with this for the first time, and tried to find different ways to solve this problem (in terms of implementation), therefore I would like to ask: does this idea can be implemented in this way or probably there is more reliable way, and which techniques or technology can be used for this realization?
Thank you!
You can do it in multiple approaches. It totally depends on the architecture you have been following.
You can use react/ key-value observing and set the keys when you get a response.
Alternatively, for a very small app or a POC, I would use alamofire as my network manager and as soon as I get a response, I would set the labels. I would use the image extension in alamofire to set the images as it takes more time to download.
I would want to know the exact problem you are facing to help you out. Generic discussion are not normally encouraged here.
This question already has answers here:
Adding Views. Storyboard VS. Programmatically [closed]
(2 answers)
Closed 6 years ago.
Is it more efficient to add views and subviews programmatically than using a storyboard to add them ?
What is be the best practice ? Does the best practice depend on the situation ? If so, when is it preferable to use the one method over the other ?
Storyboard vs Code comes up an awful lot. And I think looking at it as which is better often starts flame wars. So instead I'll list out pros and cons for each, then you can hopefully make an informed decision.
This is by no means an exhaustive list. I'd love to see edits or comments adding additional bullet points.
Storyboard Pros
Storyboards are great for getting a concept working quickly.
They're great for seeing your actual app and previewing it on multiple devices.
They make it really easy to customize appearances and explore whats possible.
They're fantastic for beginners as they remove one barrier and let you focus on code for your app rather than some boiler plate UI.
Storyboard Cons
Storyboards and Xibs are not great for merging. Its possible to read the XML and make decisions about merge conflicts, but its certainly not enjoyable.
Overtime as you customize your app and build the custom parts that make it special, Storyboards can't keep up. This means that the benefit of seeing and previewing your app as you see it on device slowly loses its value as more and more of your app is done in code out of necessity.
Storyboards don't have a huge performance hit for actual users, but they definitely slow Xcode down on even the fastest machines.
You can't customize everything in Interface Builder that you can in code, so its inevitable you'll have some code and some Storyboard customization. Later when you want to change something, you'll have to check at least two places for the right place to change it.
If you're using the same fonts and colors throughout the app, its easy to change in code in one place. In Storyboard you'll need to change it for every single label or view you've set up. You can easily set fonts and colors in code while using Storyboard for the rest of your layout, but over time you'll find your storyboards represent less and less of your actual app.
While its possible to have pixel perfect designs in Storyboard, drag and drop isn't as precise as entering specific numbers. Storyboard does support entering those numbers, but you need to navigate to multiple places and if you drag it later the numbers are all reset.
Reusing views typically involves copy and pasting them. These causes issues later when you need to make changes.
Showing and hiding views at certain times is doable, but again leaves your storyboard in an unrealistic state compared to your actual app.
Programmatic Pros
All your code is in one place making it easier to debug or change later.
Subclasses and custom properties are no different from first class views and properties. Your customizations will be easy to manage.
Views that are reused throughout the app only need to be created once.
Merge conflicts are often easy to understand and make decisions.
Dependency Injection is one of the safest ways to instantiate UIViewControllers and ensure necessary information is passed in, its not possible with Storyboards leading to less straight forward and more bug prone code.
Programmatic Cons
The additional complexity can be a stumbling block for beginners.
Writing a few lines of code can take longer than clicking a few checkboxes.
When working with layouts, you'll need to visualize it in your head or run your app to see what your layout looks like as you make changes. This can be difficult or slower for some.
Storyboard exposes checkboxes and buttons for many customizable properties like background color, font, etc. This makes it easy to see at a glance what you can customize. (Though as mentioned above its not everything) In Code, you'll need to look at documentation or headers to understand what you can customize.
I'm new to ios, and I've already got my design ready, now I don't know is there a best practice for me to do the following thing:
I have 1000 cards, each of it is like this:
And when I slide right, it will get the next one, I slide left it will back to the previous one
I can implement this now, but I can only implement this one by one for 1000 times.
In addition, when I click the middle of the card, it will flip horizontally, then show the translation. it's the second kind of card with different language and color.
So is there any hint for me? any loop can do it?
update
About data-drive, so I thought about database, and I search the google that there's four way of persistence in ios,
I decide to choose sqlite, is it a wise choice?
Reason:
I'm familiar with mysql, and use sqlite in rails before
sqlite is not too big.
I need to save original sentence, translate sentence, saved or not flag, additional story.
I've got an UIScrollView and in it different images (about 30). I'd like to make it possible, when user reaches the last image to show the first one after it and so on. And I want to implement the same feature with the first image (to go to the last one). I'd like to loop the images smoothly that user won't even notice that he is making another loop.
Here's an article on how to do it. It describe how and also include code - even if it's in Objective-C (but it should be easy to convert to C#).
I am working with a small camera app for a client and I have now finished all functionality of it. In the standard camera controls i need to modify one thing , the cancel button should say gallery instead.
But unless i am missing something i will need to remove the overlay by setting showsCameraControls to NO and then building my entire overlayView from scratch.
I have found this solution but I am afraid to go this route due to the warning in the beginning of the post.
So is there any valid way of doing simple small modifications to the existing camera overlay control UI or do you have to build it from scratch if you need to change one tiiiiiiny thing?
Unfortunately, having been in this situation I can safely say you need to build the controls from scratch. You really only have two options: create your own camera overlay, or use the default one.
Now, you could use the techniques described in the link you cite, and iterate through the various subviews and modify them 'blind'. The rather large danger with this is every time Apple change the internal structure of the image picker it could potentially break your solution. So I'd definitely stay clear of it.