Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

Doctor w-rw-rw-: Jun 24, 2008

2008? Definitely not. That's nine years, not four or five. Check for minimum supported hardware and you'll find that the appropriate version of macOS won't run on that, so neither will Xcode.

# ? Apr 13, 2017 17:36

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 17:30

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Is it still cheaper for Brazilians to fly out of the country and buy hardware there than to buy it in Brazil? I remember that being the case a few years ago. Brazil has an insanely high tariff on technology imports.

# ? Apr 13, 2017 18:11

Elias_Maluco: Aug 23, 2007; I need to sleep

Doctor w-rw-rw- posted:

2008? Definitely not. That's nine years, not four or five. Check for minimum supported hardware and you'll find that the appropriate version of macOS won't run on that, so neither will Xcode.

From what Ive read, I need at least XCODE 8, which needs at least Sierra 10.12 or El Capitan 10.11.5

rjmccall posted:

Is it still cheaper for Brazilians to fly out of the country and buy hardware there than to buy it in Brazil? I remember that being the case a few years ago. Brazil has an insanely high tariff on technology imports.

Hardly. Plane tickets are also extremely expensive

edit: might be cheaper if you buy a lot of stuff, but then you have a good chance of being barred at the customs office back home and forced to pay taxes for all of it, and then you are hosed

Elias_Maluco fucked around with this message at 18:20 on Apr 13, 2017

# ? Apr 13, 2017 18:13

FAT32 SHAMER: Aug 16, 2012

when i worked for the local fruit stand Brazilians were coming in so frequently to buy MacBooks to take home with them that they hired a couple of people who spoke portuguese

They were mostly coming in due to GM/FCA expanding into BR heavily but that's my personal anecdote :3:

# ? Apr 13, 2017 18:28

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Elias_Maluco posted:

Hardly. Plane tickets are also extremely expensive

edit: might be cheaper if you buy a lot of stuff, but then you have a good chance of being barred at the customs office back home and forced to pay taxes for all of it, and then you are hosed

Ah, maybe it was more of a "while we're here anyway" sort of thing.

# ? Apr 13, 2017 18:46

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Elias_Maluco posted:

From what Ive read, I need at least XCODE 8, which needs at least Sierra 10.12 or El Capitan 10.11.5

As of Xcode 8.3, the minimum system requirement is 10.12.

# ? Apr 13, 2017 19:11

Doctor w-rw-rw-: Jun 24, 2008

And the minimum system requirements get bumped pretty regularly so if you get the lowest-end one now your effective lifetime is gonna be pretty low.

# ? Apr 14, 2017 07:43

Doc Block: Apr 15, 2003; Fun Shoe

Definitely get something post-2012 if at all possible.

# ? Apr 14, 2017 08:01

uncle blog: Nov 18, 2012

What's a good way to easily style my app consistently in a tidy way (in Swift)? Such that I can easily change values for primary and secondary background color, font color, clickable color etc. Right now I have a initStyle function in each VC where I apply values to every outlet from a custom style extension. But since this is starting to become a gently caress-ton of outlets, I'm thinking there must be a better way.

# ? Apr 16, 2017 03:26

Glimm: Jul 27, 2005; Time is only gonna pass you by

uncle blog posted:

What's a good way to easily style my app consistently in a tidy way (in Swift)? Such that I can easily change values for primary and secondary background color, font color, clickable color etc. Right now I have a initStyle function in each VC where I apply values to every outlet from a custom style extension. But since this is starting to become a gently caress-ton of outlets, I'm thinking there must be a better way.

I generally create a static class that contains fonts / colors / sizes used consistently throughout the app and apply them when I am creating my views. I do all the views in code though, I really don't think there is a good way to style everything consistently with IB.

An approach I've seen before that I didn't like: create a custom subclass for views you want styled and change the class in IB to the subclass. That's the sort of thing that got me not to use IB for anything.

# ? Apr 16, 2017 03:50

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Make a Theme type, have views and view controllers optionally be Themeable which requires your "apply this theme" method, then walk your view and view controller hierarchies and pass your instance of Theme into each Themeable you come across. It's up to each Themeable to decide what and where to apply from the theme.

This will probably not obviate your giant pile of outlets, but it'll let you mix and match various strategies if you want to you around. For example, having a HeadlineLabel might be handy if you have a lot of different cell nibs that all need the same font applied. For bonus points you can make your subclasses IBInspectable. But if you've got a view controller with a lot of one-off stylings, just apply the theme there and don't bother making a million single-use types.

Also this scheme is easy to adapt into changing themes at runtime, useful as a possible feature in the app and (if you get real fancy) as a development aid to skip some long slow recompiles just to test a colour swap.

Not sure there's a better way other than abusing the poo poo out of User-Defined Runtime Attributes to shoehorn some theming support into Interface Builder.

Also caseless enum is cooler than static class.

# ? Apr 16, 2017 04:33

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

UIApperance can style all instances of a specific view, all instances when contained within a specific container type, and/or under certain trait collections.

There are third party libraries for applying CSS-esque systems to UIKit but I've never used any of them.

# ? Apr 16, 2017 07:30

FAT32 SHAMER: Aug 16, 2012

Does Xcode have something similar to Android Studio's UiAutomator? I know Appium/Selenium exists but it's not exactly very good and I figured if Google managed to bundle a handy testing automation library in with Android Studio surely Apple must have something similar

# ? Apr 19, 2017 02:14

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

UITesting

Good luck.

EDIT: Incidentally, I have some things I've figured out with it in my TIL repo. Let me know if you find anything wrong/broken, please.

Axiem fucked around with this message at 02:38 on Apr 19, 2017

# ? Apr 19, 2017 02:31

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

I don't know much of anything about android but you might be looking for user interface testing?

# ? Apr 19, 2017 02:32

Doctor w-rw-rw-: Jun 24, 2008

For UI testing I've heard KIF (https://github.com/kif-framework/KIF) is pretty useful

# ? Apr 19, 2017 03:01

FAT32 SHAMER: Aug 16, 2012

Axiem posted:

UITesting

Good luck.

EDIT: Incidentally, I have some things I've figured out with it in my TIL repo. Let me know if you find anything wrong/broken, please.

pokeyman posted:

I don't know much of anything about android but you might be looking for user interface testing?

Hmm, I guess older versions used to have this

But unless they moved its location, I guess it's dead

:rip:

me I guess

Doctor w-rw-rw- posted:

For UI testing I've heard KIF (https://github.com/kif-framework/KIF) is pretty useful

This definitely looks better than Appium, I'll have to check it out. Thanks!

FAT32 SHAMER fucked around with this message at 14:40 on Apr 19, 2017

# ? Apr 19, 2017 14:35

Doh004: Apr 22, 2007; Mmmmm Donuts...

funny Star Wars parody posted:

This definitely looks better than Appium, I'll have to check it out. Thanks!

KIF has been around for a while, at least has a bigger community around it.

Apple introduced https://developer.apple.com/reference/xctest/xcuiapplication a couple years ago which does what KIF does. I haven't touched it in a year because poo poo never worked. Maybe it does now.

# ? Apr 19, 2017 17:59

Hughlander: May 11, 2005

Doh004 posted:

KIF has been around for a while, at least has a bigger community around it.

Apple introduced https://developer.apple.com/reference/xctest/xcuiapplication a couple years ago which does what KIF does. I haven't touched it in a year because poo poo never worked. Maybe it does now.

We used KIF for awhile but moved away from it. I should see if we can get our changes open sourced. I think one problem was that they rewrote most of the API and we didn't want to rewrite all of our test code. Eventually we had to segregate it in it's own .a as the version we were on didn't support ARC.

# ? Apr 19, 2017 20:01

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

funny Star Wars parody posted:

Hmm, I guess older versions used to have this

But unless they moved its location, I guess it's dead

me I guess

That was replaced by XCTest-based UI testing in Xcode 7. It supports macOS, iOS, and tvOS, and lets you write your tests in ObjC or Swift rather than JavaScript.

# ? Apr 20, 2017 10:28

uncle blog: Nov 18, 2012

I've made custom code to change the color of tableView cells when they are selected, and make them transparent when they are deselected. Trouble is that the app crashes whenever it tries to deselct a cell that's been deloaded. Is there a way to reference these deloaded cells, or do I need a completely different method to do what I want?

# ? Apr 24, 2017 23:00

Kallikrates: Jul 7, 2002; Pro Lurker

is your tableView making assumptions about the lifecycle of cells it reuses? Or, is this custom drawing code within TableViewCell that that responds to changes in isSelected and setSelected?

# ? Apr 24, 2017 23:27

uncle blog: Nov 18, 2012

I honestly don't know the answer to your first question. I've just added code for the delegate methods of UITableView: didSelectRowAt and didDeselectRowAt, which both try to change the color of the cell at the indexPath, which is where the issue arrives when the cell that's deselected is unreachable.

# ? Apr 24, 2017 23:59

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

I would think it's safe to grab the cell at a selected or deselected index path from within the delegate methods. Can you post the code and/or the crash report or console log?

# ? Apr 25, 2017 00:22

Doh004: Apr 22, 2007; Mmmmm Donuts...

uncle blog posted:

I honestly don't know the answer to your first question. I've just added code for the delegate methods of UITableView: didSelectRowAt and didDeselectRowAt, which both try to change the color of the cell at the indexPath, which is where the issue arrives when the cell that's deselected is unreachable.

You should just be able to call cellForItem(at indexPath) and optionally unwrap it as a UICollectionViewCell in the didDeselectRowAt delegate method. If the cell exists (it's optional), then you can change the selectedColor.

# ? Apr 25, 2017 15:39

uncle blog: Nov 18, 2012

Doh004 posted:

You should just be able to call cellForItem(at indexPath) and optionally unwrap it as a UICollectionViewCell in the didDeselectRowAt delegate method. If the cell exists (it's optional), then you can change the selectedColor.

And if it doesn't exist, the background isn't changed, and it still appears selected when the user scrolls it into view.

Here is the code:

code:

    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        _selectedProject = _storedProjects[indexPath.row]
        if let selectedCell:UITableViewCell = tableView.cellForRow(at: indexPath) {
            selectedCell.backgroundColor = Style.cellHighlighted
        }
        loadProjectDetails()
    }
    
    func tableView(_ tableView: UITableView, didDeselectRowAt indexPath: IndexPath) {
        if let selectedCell:UITableViewCell = tableView.cellForRow(at: indexPath) {
            selectedCell.backgroundColor = UIColor.clear
        }
    }

I've fixed the issue by also including a condition in the cellForRowAt method. So now things work the way they should, but the whole thing feels very clunky and verbose.

code:

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = storedProjectsTableView.dequeueReusableCell(withIdentifier: "ProjectCell", for: indexPath) as! ProjectCell
        cell.configureCell(project: Project(projectName: _storedProjects[indexPath.row])!)
        if _selectedProject == _storedProjects[indexPath.row] {
            cell.backgroundColor = Style.cellHighlighted
        } else {
            cell.backgroundColor = UIColor.clear
        }
        return cell
    }

# ? Apr 25, 2017 20:53

Vesi: Jan 12, 2005; pikachu looking at?

That does look nasty indeed, can you call reloaddata in select and deselect instead so you can handle all cell drawing in cellForRowAt?

# ? Apr 25, 2017 21:36

Glimm: Jul 27, 2005; Time is only gonna pass you by

Since you're already subclassing UITableViewCell it might be reasonable to override the setSelected(_:animated:) method and set the background based on the incoming selected value. Is there any issue with that approach?

# ? Apr 25, 2017 22:24

Dog on Fire: Oct 2, 2004

Glimm posted:

Since you're already subclassing UITableViewCell it might be reasonable to override the setSelected(_:animated:) method and set the background based on the incoming selected value. Is there any issue with that approach?

I've always felt that it kind of doesn't go well with the MVC system, the view knowing what its selected and unselected states are and setting its properties according to them

.

But yeah, if I recall correctly from past projects, I myself have kept the stuff in the didSelectCell/Row methods to the minimum. I think I've usually stored the selected row or indexpath in some property and then just reloaded the whole tableview or the necessary cells. And then I've done the actual coloring or what have you in the cellForRow or willDisplayCell method.

# ? Apr 25, 2017 23:12

Doh004: Apr 22, 2007; Mmmmm Donuts...

uncle blog posted:

And if it doesn't exist, the background isn't changed, and it still appears selected when the user scrolls it into view.

Here is the code:

code:

    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        _selectedProject = _storedProjects[indexPath.row]
        if let selectedCell:UITableViewCell = tableView.cellForRow(at: indexPath) {
            selectedCell.backgroundColor = Style.cellHighlighted
        }
        loadProjectDetails()
    }
    
    func tableView(_ tableView: UITableView, didDeselectRowAt indexPath: IndexPath) {
        if let selectedCell:UITableViewCell = tableView.cellForRow(at: indexPath) {
            selectedCell.backgroundColor = UIColor.clear
        }
    }

I've fixed the issue by also including a condition in the cellForRowAt method. So now things work the way they should, but the whole thing feels very clunky and verbose.

code:

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = storedProjectsTableView.dequeueReusableCell(withIdentifier: "ProjectCell", for: indexPath) as! ProjectCell
        cell.configureCell(project: Project(projectName: _storedProjects[indexPath.row])!)
        if _selectedProject == _storedProjects[indexPath.row] {
            cell.backgroundColor = Style.cellHighlighted
        } else {
            cell.backgroundColor = UIColor.clear
        }
        return cell
    }

Not really an "issue" as that's how it's supposed to work. You're supposed to configure your cell in the cellForRow delegate method - selected or not. It makes sense that if you're scrolling a cell back into view, you'd need to ensure it has its proper state.

Vesi posted:

That does look nasty indeed, can you call reloaddata in select and deselect instead so you can handle all cell drawing in cellForRowAt?

I'd be careful calling reloadData. It's an expensive call and calling it midway through other delegate methods will generally lead to funky behavior.

Glimm posted:

Since you're already subclassing UITableViewCell it might be reasonable to override the setSelected(_:animated:) method and set the background based on the incoming selected value. Is there any issue with that approach?

This is generally the way to go, that said I've never had 100% success using JUST the built in selection mechanics and ended up having to store that state somewhere.

# ? Apr 25, 2017 23:14

uncle blog: Nov 18, 2012

I'm sticking with that solution for now.

A new problem is that when I slide a cell to the left (since I've implemented editActionsForRowAt), the styling gets all messed up. Is there a way to detect if a cell is being slided to the left, and then call a method?

# ? Apr 29, 2017 15:50

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

uncle blog posted:

I'm sticking with that solution for now.

A new problem is that when I slide a cell to the left (since I've implemented editActionsForRowAt), the styling gets all messed up. Is there a way to detect if a cell is being slided to the left, and then call a method?

The cell itself has some methods you can override. Something about state or edit state.

# ? Apr 29, 2017 19:22

DEAR RICHARD: Feb 5, 2009; IT'S TIME FOR MY TOOLS

I'm building my first app right now and it's kicking my rear end. I feel like there are solutions right in front of my face for some problems that I'm having, , but I can't seem to focus on one thing at a time to try to fix.

The app I'm building uses a Google maps interface that will let users drop pins and upload an infowindow with a picture/location/short description of something. The problem is I have ideas of what to do, but trying to figure out what to do first is somewhat difficult.

I've followed along with the google developers guide up until it gets to the set current location part. I have the map built with a hard location (long, lat), but I don't think I want that right now.

edit: using swift

DEAR RICHARD fucked around with this message at 00:26 on May 8, 2017

# ? May 7, 2017 23:14

SaTaMaS: Apr 18, 2003

I'm working on a data-driven app that uses CATiledLayer (inside a UIView) inside a UIScrollView, but I'm not sure how to make it append new tiles on the right side while scrolling to the left side, as I get new data. On each update I make the contentSize wider and move the contentOffset backwards, but instead of adding on new tiles, it just stretches out the existing tiles.

edit: Just needed to change the contentMode and call setNeedsDisplay() on the UIView

SaTaMaS fucked around with this message at 16:38 on May 9, 2017

# ? May 9, 2017 16:20

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

DEAR RICHARD posted:

I'm building my first app right now and it's kicking my rear end. I feel like there are solutions right in front of my face for some problems that I'm having, , but I can't seem to focus on one thing at a time to try to fix.

The app I'm building uses a Google maps interface that will let users drop pins and upload an infowindow with a picture/location/short description of something. The problem is I have ideas of what to do, but trying to figure out what to do first is somewhat difficult.

I've followed along with the google developers guide up until it gets to the set current location part. I have the map built with a hard location (long, lat), but I don't think I want that right now.

edit: using swift

I can't tell if you're just venting here or if you have a question we might be able to answer. Either is totally fine, I just don't want you to think you are being ignored!

# ? May 9, 2017 19:14

brap: Aug 23, 2004; Grimey Drawer

So I've been having moderate success using this utility for generating Xcode projects from a human-readable, diffable script.

https://github.com/jcampbell05/xcake

When I tried it at first, I had to manually fetch version 0.7.1 because the latest would crash when I tried to run it. The documentation is also a bit sparse. Despite this, I feel pretty happy about using it.

My project is just a small 4-person deal, but so far we've found that:

1. Making the file system the "canon" on where things are located, and always knowing our Xcode groups are isomorphic to our real folders is very helpful.
2. Not having to ever merge .pbxproj--actually, .gitignoring everything under .xcodeproj has saved us a lot of headaches.
3. Xcake is pretty good at "just doing the right thing" a lot of the time, i.e. putting files in the appropriate build phase based on their type, and so on.
4. When we need to do something unusual, we have decent luck searching the Xcake issues for someone doing something similar.

# ? May 12, 2017 19:44

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

fleshweasel posted:

1. Making the file system the "canon" on where things are located, and always knowing our Xcode groups are isomorphic to our real folders is very helpful.

I have a couple coworkers who swear by this at work, but I've yet to have any of them actually articulate what makes it better.

# ? May 13, 2017 02:09

brap: Aug 23, 2004; Grimey Drawer

Having a grouping structure in Xcode that diverges from the file system structure makes it harder to find your poo poo if you ever want to log or blame or checkout other file versions or any number of things. There's no reason to keep two different mental models of "where my files are in my project".

# ? May 13, 2017 02:27

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Right, that's why my mental model of file location is "it's in the quick open box".

# ? May 13, 2017 04:25

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 17:30

brap: Aug 23, 2004; Grimey Drawer

edit: oops, accidentally edited instead of making a new post.

brap fucked around with this message at 17:44 on May 13, 2017

# ? May 13, 2017 06:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »