I'm attempting to learn Xcode currently, and instead of reading a lengthy tutorial, I much prefer to learn by doing. Therefore, I'm looking at some of the sample code from the Apple Developer website and learning the ins and outs of the code. I'm currently learning about Core Data (https://developer.apple.com/library/ios/samplecode/iPhoneCoreDataRecipes/Introduction/Intro.html) but I ran into a problem. There's a button that links me to "Categories" in which I can select a category to put a recipe in. The categories are connected to an SQLite database best I can tell. However, I'm trying to delete this button, and I can't find out where the button is in any of the code. If anyone knows an easy way to locate and delete a button through the simulator, I would really appreciate it, or if anyone would have the time to look over the code and see where the button is (It's right below Prep Time and directly above Ingredients) and see how to delete it, I would be very appreciative. Any help is greatly appreciated. Thanks.
From Apple's introduction to Core Data:
Important: Core Data is not an entry-level technology. Before starting
to use Core Data, you must understand the basics of iOS application
development, including:
How to use Xcode and Interface Builder
Fundamental design patterns such as model-view-controller and delegation
How to use view controllers, navigation controllers, and table views
The sample code you linked to has some very helpful info for learning Core Data, but you should really learn the ropes of Xcode, etc. first. Additionally, the project doesn't use Storyboards and appears to be targeting iOS 3.2. You may want to check out some sample code that targets a more current version of iOS and integrates Storyboards if you're just getting started. If you're dead set on starting with Core Data, start by picking apart the Master Detail Application template--it's much easier to consume (pun intended).
If you must know, the "Category" button is actually a UITableViewCell. It resides in RecipeDetailViewController.m and triggers a push transition to the TypeSelectionViewController when tableView:didSelectRowAtIndexPath: is called.
If you want to get rid of the cell and the title for the section, comment out lines 249 and 228 - 230.
Line 249:
// case TYPE_SECTION:
Lines 228 - 230:
// case TYPE_SECTION:
// title = #"Category";
// break;
Stop now, don't pass go. Thank me later.
If you search the project for the word "Category", you can see that it's a section in a tableview inside RecipeDetailViewController:
This app-wide search function (which admittedly only scans code, not NIBs or Storyboards) is very useful.
This tells us that this is not part of the UI defined by the NIBs, but rather a UI generated from code (it's a section in the table view). As you can see from that code, that means that the section whose section number is equal to TYPE_SECTION results in the "Category" behavior. So search the code for all occurrences of TYPE_SECTION, and comment that out of the code. Because these section numbers are integral to the code (and have to start at zero), you have to adjust the constants that say:
#define TYPE_SECTION 0
#define INGREDIENTS_SECTION 1
#define INSTRUCTIONS_SECTION 2
and replace that with something like:
// #define TYPE_SECTION 0
#define INGREDIENTS_SECTION 0
#define INSTRUCTIONS_SECTION 1
This code, rather gracelessly, has hard-coding for the number of sections, too, so you'd probably have to fix that, too, namely, replacing:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 4;
}
with
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 3;
}
This is, at my quick investigation, what you need to do. There might be other things you'd have to do, too. If this was a UI element defined by a NIB or storyboard, the process of hunting it down is a little different (and sufficiently more cumbersome that I hesitate to go into it here ... the answer to that question is (a) not applicable to your immediate question of how to remove the "Category" section and (b) a detailed answer on searching NIBs would probably be more confusing than helpful; if you really want me to describe it I can, but it's probably not a good use of your time as you're just getting started).
Having said all of this, if you're looking to learn, diagnosing really old code might not be the first avenue I'd suggest.
I would, instead, suggest following some tutorials that walk you through the creation of your own test apps (e.g. Apple's "My First App" described in Jump Right In section of the Start Developing iOS Apps Today guide; or the Second or Third app that they describe in Where to Go From Here? section at the end of that guide.
Actually writing your own code (simplified by following along a tutorial like these) is going to be a heck of a lot more productive than trying to reverse engineer some old code (IMHO).
The interface is probably in a xib file. But if you are learning in this way, you will have to accept you will run into stuff where a more formal approach would probably have helped you.
Related
I'm programming in iOS not so long. I was mainly programming UI related stuff like animations, custom UIControls etc.
I need in my new app to:
Display loading activity indicator and in the same time:
load some remote data from server parse them and store in local core data
load some data from local core data
get user position from location service
After this I have all data needed to display next view controller and dismiss loading indicator.
Question is how can I do this all? I need to support iOS9, iOS10, 11, 12. I understand that this needs to be done in background threads and then I need to merge all data from each task and switch to next view controller. I can't use any external libraries like rx-swift or promise-kit. Maybe there is any experienced iOS developer who can give me some main guidelines how to approach to this kind of application flows? I can imagine there is a lot of ways I can do it some of them are better and some of them are worse. Any guidelines would be very helpful for me. Thanks.
It's a very complex question and as you said it's possible to solve all this problems in several ways. But for sure i can give you some core-hints about which steps is better to follow:
Run in a separate thread the management of all stuff regarding to the Network communication. Maybe you can run it on a separate queue using the class DispatchQueue(). Once you received the data, in the same thread, maybe you can directly convert these information and store them inside a CoreData database.
To store into CoreData you need at first to know how it works, so basically search for some really easy tutorial about how to create from zero your first database inside XCode. After you have been able to run and execute a very simple one you will be able to pass to the second step and so try to integrate it with the data you have previously downloaded from the network. Here a good article for you: https://www.raywenderlich.com/7569-getting-started-with-core-data-tutorial .
To get the location is a separate field of study, because you have to study which background modes are allowed in iOS (And actually are allowed just a few). After that you will need to figure out in which category of background-location application your software belongs. After that you have to dig deep and discover how protocol and delegates works inside Swift/Objective-C in order to properly manage the last location value retrieved by the sensors. Here is a good article for you: https://www.raywenderlich.com/5247-core-location-tutorial-for-ios-tracking-visited-locations.
At the end when you interconnected all this flows you can think about how to display the loading indicator. Basically you need to drag and drop it from the tools into the storyboard, interconnect it by using the IBAction or IBOutlet, depending on when you wanna show it and in which specific case. And then use the relative method startAnimating or stopAnimating in the right code flow (It really depends on how you have structured all the previous bullet points).
Since your question was very general and it includes a lot of sub-steps, basically it really needs to be thorough studied and analysed.
I've tried to sum up as much as possible the most important bullet points. I hope the links i suggested to you will help a little bit. Good luck.
I’ve been a procedural programmer for a long time and most of my iOS code is written with lots of if statements instead of sub-classing. I think I finally understand how to write object oriented code but I have a few questions.
I have a class, ScoringToolbar.m that is used in all of my games. It creates buttons for the bottom of the screen. Which buttons are created vary depending on the game and the options in the game. Here’s a typical screen.
Right now it is a long series of if statements. In addition to being hard to read, it’s definitely not proper object oriented programming. What I’d like to do is convert the class into a superclass and add a subclass for each game. My first question is: Is there a convention for naming the superclass?
Also, I’d like to keep the ScoringToolbar.m name for each of my sub-classes. If I create one sub-class for each of my apps (or group of similar apps) I can move the code from the if statements into it. Then each app would call its own subclass and create the buttons it needs. If I do that I won’t have to change any of the calling code. However, if I have lots of .m files with the same name, what do I do with the .h files. Do I have just one and make sure it works with all of the .m's. Or is there a way to tell Xcode to use a specific .h file in an app?
Or is this the wrong approach altogether?
I'm not sure subclassing is your best option. Your question about multiple .m files with the same name suggests this approach might get confusing. You might want to think of your ScoringToolbar as a control that your apps configure for their needs. In this way it wouldn't be much different than a UIButton. Each app would be responsible for creating an instance of the ScoringToolbar and setting it up to suit. It could do this in a method in an existing class or in a helper class. The ScoringToolbar takes care of rendering the UI (icons, colors) while the calling app indicates what options it needs (up/down votes, number correct/incorrect, etc).
I think subclassing is not a good option for you problem. You will end up with code which is hard to maintain and modify when your apps or no of apps grow big.
Have a look at some design patterns, if I got your problem correctly, builder pattern would be one of the options.
Or you can create configuration file for each game. For example you can have an array of dictionaries in a plist. Each dictionary will represent a UI element in the toolbar. For example you can store the image name, order, selector, position(?) and etc in the plist. When loading the application you can create the toolbar elements at run time using the dictionary options.
These are just a starting point but based on your requirements and extendability of your apps you can find better solutions.
Hello I am building forms over and over in iPhone and iPad apps:
Custom UITableViewCells for labels with input
Localization for labels, placeholder text and section headers
Validation that marks the cells red or something and does not allow "Submit" if form is incomplete
Clicking in the cell activates the editable text box
Next / previous buttons
Reliable across devices, orientations, iOS versions
I can't imagine I'm the only one doing this. Is there a mature framework or something that can drop in and use? Could you please comment on how you use this library with designs other than vanilla UITableViews with your own colors etc.?
Take a look at IBAForms - an open source project from from Itty Bitty Apps. I haven't used it yet myself, however I believe it does most of what you want, except for validation. Here is the github page: IBA Forms
It hasn't been maintained in a while, but if you're looking for a forms library - it's mature and works. At the very least, it could be the starting point for something you take further.
Update: There is also Chris Miles' EZForm library, which is very nice.
Update #2: Have also started checking out QuickDialog, which seems to be very popular.
Update #3: Nick Lockwood has created one called FXForms
Update #4: Martin Barreto has created one called XLForm
I don't know if this counts as an answer, but i use Sensible Cocoa - Sensible TableView (STV) for this purpose a lot. It's not a "forms" framework (on top of UITableView) as such, but it can be used for this purpose in a very flexible way. It still requires some coding to build a full-fledged form but the UITableView/UITableViewController boilerplate code is reduced to a minimum. Unfortunately the developers bumped the price tag quite high with version 3.0, so i'm actually looking for a STV replacement right now. (I'd stick with STV if it wasn't for the price!)
I don't know of anything that combines all those features, but I recently open-sourced my validation library PMValidation on github, which I used developing the iPhone app Imprints. PMValidation comes with many basic types suitable for validating forms, and in fact that's what I originally built it for.
Using the PMValidationManager class you can easily listen to UITextViews or UITextFields, and update whatever graphical widgets you want via notifications. It's very modular and easily extendable, should you have more unique needs. It's under the MIT license.
I have a pretty much standard UITableView, but I would like to change it to look like what would be considered a normal table outside iOS development -- make it have more columns (but just one row) and make the cells square-shaped.
I thought about making more tables (one for every cell) and then placing them next to each other, but that wouldn't be so convenient.
Is there maybe a simple way to make cells go on the right of the one before instead of going below?
Use some third-party classes that allows you to have "Grid Views".
One is my OHGridView class, another is NRGridView, and there are many more. If your app needs to be compatible with iOS4 and/or iOS5, using a third party class (or building one yourself) is the only option.
Under iOS6, there will be some other stuff that allow you to do that directly (iOS6 still under NDA so we can't talk about it publicly yet, but go read the API Diff files in the developer.apple.com website if you have access to them). So if your app is intended to be compatible only starting iOS6+ and you don't need support for iOS5, this could be the solution and you should go read about it if you have a developer account with access to the iPs6 SDK.
What you're looking for us UICollectionView.
As with my previous "vs" question at BlackBerry: Overriding paint() vs subpaint() I am wondering if this has to do mostly with convention, style, or if there are some real hard n fast rules.
The way I've seen it so far is that MainScreen.setBanner(Field) and MainScreen.setTitle(Field) have almost exactly the same functionality. I have used the case of being able to call setTitle(String) in a simple UI. However I am working across iOS, droid, BB, and try to make the UIs similar - my title/banner is a 'pretty' custom manager.
The only difference I can see is the little style element that is inserted automatically under a title.
Is this the only reason I would have to choose between using each of these methods?
Perhaps there are stylistic or convention reasons to use one over the other? Perhaps RIM has some intentions with these methods that I cannot yet see as a new BB developer? Am I making a mistake by treating these methods as direct substitutes?
If you use both, the banner is laid out above the title. My understanding is that if you are using only one, then they are pretty much interchangeable -- the reason to have both is that you can get some stacking behavior if you want to add more information to the top of the screen.
There is an article: "MainScreen explained" that goes into detail on this and other features of MainScreen.