I'm very new to Swift programming and one of my first projects is to create a spinning wheel/scroller for a list of ~20 items.
I decided that the best strategy would be to implement what Apple already has: a UIPicker. Unfortunately I also learned that Apple doesn't natively support looping around (i.e. going from 59 back to 0).
This is an issue because the purpose of my project is to allow the user to spin and obtain a "random" result based on the spinner. This doesn't work so well when you are spinning and landing at the top or bottom.
I have looked online for help but everything I found is generally about 4 years old (or more) and thus very outdated. I am new to swift programming and really do not understand this stuff well enough to implement their designs.
I would love an updated strategy for implementing a looping UIPicker or even some other suggestions about how to go about this project. The major problem with other strategies is that I would need to display 20 options which just wouldn't work well with a spinning wheel image.
Related
an iOS app page, which descirbes some item's detail
This is kind of what I want to make
This is exact what I want
Actually I am not an iOS developer.
But a member of our team lacks of knowledge of consisting of iOS app Page(Scene)
I think he usually use table view all the time. which I guess he can't handle very well.
He always struggle about height of UITableView in dynamic pages.
As you see in the picture, page has two views, which I don't know how to call it.
If round button on the right side of a woman is pressed those two views switches.
I guess it's kind of "TAB".
Is it normal that using UITableView in this kind of page. or Which is best practise?
Thanks in advance and sorry for my english.
The first image can be made using a UITableView or UICollectionView(UITableView will do the job with lesser hassle). For second image, you'd wanna use a segmented control.
The third can be built using UICollectionView, however, there are plenty of third party libraries out there on github for the same and you might wanna check them out.
Last but not the least, have some faith in your developer. He seems to be a newbie if he's facing troubles with tableviews but believe me, we've all been there some day.Encourage him to ask questions on various communities. If he's curious enough, he'll be just fine after a while.
I’m a relatively new app developer working on a couple of individual projects. I’ve dumped at least one hundred hours into coding using Swift in Xcode, and, as embarrassing as it may be to admit, it seems I can’t fully grasp or find information pertaining to how popular apps such as Facebook, Instagram, YouTube, or Tinder implement non-linear view navigation via a menu bar at the bottom of the screen.
I’ve seen one particular app tutorial series that exemplifies how to go about making this menu bar style possible using a collection view of horizontally-placed views each equivalent to the size of the screen. I understand this gets rid of the issue of loading new views on top of existing old ones that sit in the background (my primary worry, outside of unnecessarily reloading information), but is this the typical method of implementing non-linear menu navigation in an app? I suppose a more pressing question at this point is “How can I go about making something like this using SwiftUI?”
If anyone can offer information, explanations, and/or sources, they would all be much appreciated. Thank you for your time!
So, upon receiving TylerTheCompiler’s comment on my post, I started researching the UITabView. It appears that this is used for creating exactly what I was trying to explain in the initial post. I subsequently searched for a way to implement this in SwiftUI and found the “tabbed view.” The tabbed view seems very easy to implement and is exactly what I’ve been looking for. I still wonder if popular applications have been utilizing the UITabBar rather than something else more practical that I am still unaware of. If you happen to know, please comment on this post — I would love to know, myself. As always, thank you for your time, everyone!
Working on an app on which I have a few buttons at the top of the window, Hitting one of these buttons brings up a specific set of UI Elements (such as additional buttons or text fields). I was told during my Google travels searching for an answer, a best way to do this would be using more views, like showing a specific view when Button A was hit, or showing a specific view when Button B was hit. That works greatly, but it worries me. If I wanna have 20 buttons or so, would 20 different views be a problem performance wise? I just feel like thats a lot of views..
Is there a better way to go about this?
Thanks, Joe
In general the views will not be a performance problem.
Also in general don't optimize until you have a test that shows a performance problem. The key to writing good code it to write simple code that is easily understood. Later if there are performance problems investigate, find them and eliminate them. Xcode provides reasonably good tools for this in Instruments.
From Donald Knuth Premature optimization is the root of all evil (or at least most of it) in programming.
Views are the primary building block for UI in iOS. Having a lot of views is not likely to be a problem.
However, a UI with 20 buttons is likely to be cluttered and hard to use.
I'm working on a timeline app that needs to have a Garageband-type interface. I'm not a new developer, and I have a background in CGI and have been a Mac dev for over 20 years, but I'm a little stuck on what kind of objects to make that would represent the objects in the timeline. Are they UIViews? Drawn with QuartzCore? I Googled the heck out of the concept and looked at some books and came up empty. Any ideas on how to make these objects? I'd rather ask then start in one direction and realize there could be a better way down the road. Thanks.
Given that they allow user interaction, they're probably implemented as custom UIView subclasses. Since views are layer-backed, and since the timeline isn't flying all over the place and doing crazy complex animations, there's not really a good reason to have the UI be built directly from layers.
I was wondering what would be the best configuration of view controllers and views for an app that I’ve been planning out. Conceptually, the way I would like to lay out the app is with an initial loader/browser view, likely with document thumbnails. When a user chooses to open one, a new view comes up that forms the main document-editing mode. The user can also choose to bring up a third view that contains an alternative document-editing mode.
I suppose this is very much like the way the Pages for iPad works, with first a row of document thumbnails to choose from, then the main word processing view, and accessible from a popover a third page setup view. Document browser view, and two document editing views.
Now, I can think of, and have been playing around with a few different set-ups, but in each case I can see problems that I’ll be running into later. So really, I’m looking for advice on a configuration that you think would keep things as neat and manageable as possible.
I hope this is not too open a question, and I would very much appreciate any answer.
Thank you,
I will probibly get shot in the head for making a suggeston like this, but I'll make it anyway:
In learning iOS programming, I spent a lot of time studying (as most people do - and as is taught by every tutorial on the planet) on how to use Navigation Views, and toolbars, and all the standard type views that assist in different types of navigation.
On the latest app I have been working on - I spent a lot of time and frustration trying to figure out how to best characterize what I was doing - and moreso trying to fit it into what the iOS frameworks would use to implement this stuff. Then (of course) I got stuck trying get things to do what they weren't supposed to - like when a navigation view wouldn't let me use the "back" button to jump out of the navigation herirarchy I'd set-up, etc.
In short - when I stopped worrying about the specifics of what all these different types of views and controllers were - and how they interacted and how I was supposed to do it - and started worrying about how I wanted my application to work - and working from a basis of generic views, custom toolbars, etc - the whole think made a whole lot more sense.
In my case, I liked the look-and-feel of the Mapquest app - and they way it dealt with toolbars that your could open and close from the top and bottom of the screen - which had buttons - which could switch to other views etc. So I started using "generic" views to implement this functionality - and the whole entire thing clicked together.
So in-short:
1 . I'd decide how you want it to look and what you want it to do
Use a third-party app as your inspiration, if needed
Decide when/where/if some of the "standard" practices apply - and use them where/when they do.
Have fun!
-BKG