|
Yeah, but I'll be honest here: getting two apps side-by-side in UI testing requires some fairly advanced effort. It's way harder than it should be. You essentially have to automate every painstaking step: perform a screen-edge drag to bring up the multitasking dock, find an app icon inside the dock (owned by Springboard), drag that to the screen, put the UI into split mode, etc. The difficulty curve and tedium is not lost on us! e: typo e2: This is definitely an area I think we can improve upon. Mikey-San fucked around with this message at 07:51 on Aug 2, 2017 |
#
?
Aug 2, 2017 07:48
|
|
|
|
| # ? May 15, 2024 04:17 |
|
|
Mikey-San posted:It's not you! We think there's a lot of room for improvement in our UI testing documentation. The class reference documentation does what it does, but one can imagine a variety of improvements that would help people go from 0 to 60 much more quickly. Oh perfect, hopefully these will point me further in the right direction. Thanks again! edit: holy loving poo poo xcode writes it all for you based on what you click on?  I thought android's uiautomator was pretty good but jesus. I still havent figured out how to set an app that exists on my device as the target for my tests but these have already opened my eyes  edit: if anyone would like an ez stackoverflow question answered https://stackoverflow.com/questions/45469481/how-to-perform-uitesting-on-an-app-i-dont-have-source-code-for/45469559#45469559 FAT32 SHAMER fucked around with this message at 20:56 on Aug 2, 2017 |
|
#
?
Aug 2, 2017 14:50
|
|
|
Should I be worried about iOS 11 and Swift 4 yet? I spent most of the day yesterday getting things to build in Xcode 9. I found some obvious iOS 11 bugs and some other display issues that I should address, but today Xcode 9 has decided that none of the same code will build. I'm sure this is Cocoapods's fault somehow, but I've spent hours today making no progress. It's the same god drat code, but everything is broken today. I'd really rather not spend three or four days forking every single dependency and chasing my tail if this is all bugginess that will be fixed before release.
ManicJason fucked around with this message at 20:49 on Aug 2, 2017 |
|
#
?
Aug 2, 2017 20:46
|
|
|
I ended up figuring out that enabling whole-module optimization fixed my speed issues, by the way. 1/60 of a second: 0.016666... seconds Time to process a frame without optimization: ~0.4 seconds Time to process a frame with optimization: ~0.0015 seconds  Turns out running CPU simulators with dynamic dispatch is slow, who knew.
|
|
#
?
Aug 2, 2017 21:09
|
|
|
FAT32 SHAMER posted:Oh perfect, hopefully these will point me further in the right direction. Thanks again! UI recording is a good place to start to learn how queries are constructed. It has its limitations, so it's best as a jumping-off point. (E.g., it doesn't know anything about whether you need to wait for an element to exist before attempting to interact with it.) It also can't reason about the best way to structure your tests. It just emits what you did. quote:I still havent figured out how to set an app that exists on my device as the target for my tests but these have already opened my eyes Automating an application that is already on the device doesn't involve messing with the "Target Application" setting. That setting controls what -[XCUIApplication init] does and references something in your project. If you want to reference an application that isn't from your project, you would use -[XCUIApplication initWithBundleIdentifier:] instead. E.g., code:code:e: clarity Mikey-San fucked around with this message at 21:36 on Aug 2, 2017 |
|
#
?
Aug 2, 2017 21:30
|
|
|
edit: I never said I could read
Doc Block fucked around with this message at 21:40 on Aug 2, 2017 |
|
#
?
Aug 2, 2017 21:32
|
|
|
I should also mention that UI recording only works for the default "Target Application" currently.
|
|
#
?
Aug 2, 2017 21:37
|
|
|
I have a question that's more about a basic object oriented programming thing, but I would be implementing it in swift so I figure I'll try asking here. I want to have a function that will create an object from a class, and each time the function runs it will create a new object with the name incremented by 1 (object1, object2, etc). I'd like these objects to not disappear on garbage collection. How do I go about doing that, if anyone has specific advice or a good source to read. Thanks for any help. e - Just typing out the question sometimes helps. I realized I was making things more complicated than they need be, I just want an array with one of the values being an identifier. Ocean Book fucked around with this message at 02:26 on Aug 3, 2017 |
|
#
?
Aug 3, 2017 00:04
|
|
- hi
|
Can you tell us more about what these objects are used for, or the overall task you're trying to do?
|
|
#
?
Aug 3, 2017 00:31
|
|
|
I just edited my post to say I thought of a simple solution. But to answer, they were going to hold qualities of a tile in a game.
|
|
#
?
Aug 3, 2017 02:27
|
|
|
ManicJason posted:Should I be worried about iOS 11 and Swift 4 yet? I spent most of the day yesterday getting things to build in Xcode 9. I found some obvious iOS 11 bugs and some other display issues that I should address, but today Xcode 9 has decided that none of the same code will build. I'm sure this is Cocoapods's fault somehow, but I've spent hours today making no progress. It's the same god drat code, but everything is broken today. I'd really rather not spend three or four days forking every single dependency and chasing my tail if this is all bugginess that will be fixed before release. I would guess that the most likely thing is that something accidentally (or buggily) got flipped in the build configuration. Maybe your dependencies are suddenly being incorrectly built in Swift 4 mode instead of Swift 3.2 mode? I will politely say nothing explicit about the software development approach of installing a developer preview and experiencing substantial unexpected development problems and then just ignoring them in the hopes that someone else will make them all go away. rjmccall fucked around with this message at 05:47 on Aug 3, 2017 |
|
#
?
Aug 3, 2017 05:43
|
|
|
I got things up and running again after a few hours. Most of the issues were indeed 3.2 vs 4 in Cocoapods depdendencies. I have no idea how that was changed after committing Podfile.lock and doing a pod install the second time around. Maybe something changed when I did my first 4.0 migration on my project target. I unchecked the Pods project and its targets when doing the migration, but maybe Xcode did something to them anyway. I didn't look carefully at the time before hopping around in source control. It seems like Cocoapod's approach to Swift versions is "Well, Apple keeps changing the rules on specifying Swift versions, so we're throwing our hands up and not supporting specifying Swift versions at all." [source] There was also a mystery pod that will not build in 3.2 nor 4 but was somehow building yesterday, but it's not terribly important to my project and should probably be axed anyway. rjmccall posted:I will politely say nothing explicit about the software development approach of installing a developer preview and experiencing substantial unexpected development problems and then just ignoring them in the hopes that someone else will make them all go away. You'll be happy to know that I am filing my first Radar in years for a very specific issue with UIDynamics. I'd love my cynicism from past bug reports to be misplaced.
|
|
#
?
Aug 3, 2017 19:35
|
|
|
Friend/coworker responded to someone asking about why not to use Autolayout, reposted with permission:quote:Here are the main issues I see with Autolayout as it exists currently: rjmccall posted:I will politely say nothing explicit about the software development approach of installing a developer preview and experiencing substantial unexpected development problems and then just ignoring them in the hopes that someone else will make them all go away. We're working here: when a tool is published with expectations from its developer that it will be used, the expectation from its users is that it will be quality. If we're asked for buy-in and participation in improving its quality, then you can open-source it and give people a stake in it, or you can mark it as "not there yet" (which is what the DPs are). Working around flaws because something else is more important, and ruthlessly prioritizing because of promises and deadlines which the company itself may not control is a fact of life for any org that doesn't have the cash or the slow cadence to Do Engineering RIght™. That's a luxury afforded by being able to absorb a lot of risk and accepting slow+high-quality development.
|
|
#
?
Aug 3, 2017 20:55
|
|
|
Eh, while I don't love autolayout there are some situations where it greatly simplifies the amount of code you have to write. Self-sizing table cells for example. I'm happy to be able to rip out a bunch of manual string measurement and layout code in my cells and replace it with a few constraints instead. The biggest problem with autolayout is the difficulty in debugging it. Especially when any layout problems just dump a bunch of cryptic errors in your log that you have to reverse engineer to find the source of the problem. quote:The constraint solver operates in polynomial time, which can end up being a significant problem given that you need a large number of constraints to specify relatively simple layouts quote:If you're using NSLayoutAnchor or NSLayoutConstraint and specifying individual constraints, the amount of code necessary to build simple layouts is significant and also harder to read than CK (Flexbox) or manual layout code. code:
|
|
#
?
Aug 3, 2017 23:51
|
|
|
Somehow every time I’ve tried to use self-sizing cells I’ve run into some issue that I couldn’t figure out how to solve and ended up backing out. I can’t tell if I’m unlucky or inadequate, but it’s happened several times. I’m sure I’ll try again. It seems like a no-brainer.
|
|
#
?
Aug 4, 2017 00:17
|
|
|
Thank x1000 Apple for making the user defaults file NSFileProtectionCompleteUntilFirstUserAuthentication without documenting it, you only cost us half a week  Not logging anything when the file fails to open is an extremely pro move tooe: to be fair I'm not 100% sure that nothing is logged hackbunny fucked around with this message at 01:24 on Aug 4, 2017 |
|
#
?
Aug 4, 2017 01:14
|
|
|
Doctor w-rw-rw- posted:I think that for smaller development teams, they may be able to overlook a number of these drawbacks in favor of the conveniences they get from using Autolayout, but for a company with hundreds of iOS developers working on one huge app, even the "small" problems are amplified by orders of magnitude. Not trying to get into the nitty gritty with the rest of your post, but I wanted to highlight that part of the quote. The VAST majority of us are not working with hundreds of iOS engineers. Like, I get it might be relevant at a FB, Twitter or Google, but that's really not the norm.
|
|
#
?
Aug 4, 2017 02:51
|
|
|
Hi yes hello I'm the lone person in my company that has iOS experience and it's back from iOS 6 
|
|
#
?
Aug 4, 2017 03:19
|
|
|
Doh004 posted:Not trying to get into the nitty gritty with the rest of your post, but I wanted to highlight that part of the quote. Sorry but that doesn't matter. We need to see the same guy blathering on about how amazing Facebook's team is and how Autolayout is bad over and over and over again every time anything remotely related is brought up.
|
|
#
?
Aug 4, 2017 03:34
|
|
|
hackbunny posted:Thank x1000 Apple for making the user defaults file NSFileProtectionCompleteUntilFirstUserAuthentication without documenting it, you only cost us half a week It might (it might not). https://developer.apple.com/bug-reporting/profiles-and-logs/ Some of these include profiles that enable additional Device logging.
|
|
#
?
Aug 4, 2017 03:42
|
|
|
The vast majority of apps are not under the same constraints as Facebook. HBO now makes a ton of money and uses auto layout. Washington Post is one of the top News apps; storyboards. Its up to you to experiment and find the best tool for you and your team that gets the app out there earning money as early as possible. While balancing maintenance. Apple isn't going to optimize their platform for those 5% apps that push at those boundaries, they work for those 80% apps that actually make a lot of money for Apple. Autolayout errors are much easier if you set identifiers on your constraint. The errors emitted by the console will tell you almost exactly which constraints were in conflict. (tho do open radars from those 5% apps because you'll find those edge cases better than the others - like weird NSData leaks).
|
|
#
?
Aug 4, 2017 03:55
|
|
|
Kallikrates posted:It might (it might not). https://developer.apple.com/bug-reporting/profiles-and-logs/ Some of these include profiles that enable additional Device logging. Most seem to involve triggering a sysdiagnose: is the sysdiagnose output easily readable or it's just meant to be sent to Apple? Because I remember BlackBerry 10 had something like that, but the diagnostic output file was completely unreadable and apparently encrypted e: and I don't see Foundation or UIKit in that list so I assume that the logs I get are the best I can hope for
|
|
#
?
Aug 4, 2017 08:24
|
|
|
dc3k posted:Sorry but that doesn't matter. We need to see the same guy blathering on about how amazing Facebook's team is and how Autolayout is bad over and over and over again every time anything remotely related is brought up. Don't worry, I'll eventually get annoyingly smug about something else. And besides, some of those people work at Apple now so whatever. Until then... NoDamage posted:Eh, while I don't love autolayout there are some situations where it greatly simplifies the amount of code you have to write. Self-sizing table cells for example. I'm happy to be able to rip out a bunch of manual string measurement and layout code in my cells and replace it with a few constraints instead. Part of my annoyance with it also comes from wanting to do UIGestureRecognizer velocity transfer into view animations while keeping user interaction enabled, which effectively means main threaded animation, either hand-rolled or (more likely) Pop or UIKit Dynamics. Any stutter anywhere will stutter all main thread animations, which means that even as a solo developer on the side, I felt the pain briefly before going back to non-autolayout. Add to that the undefined behavior to handle unsolvable constraints, and I can't actually model the behavior in my head in any sane way. Not super contrived, but not the common case, either, and solvable if I were willing to compromise a bit As a perfectionist control freak though, Autolayout pisses me off. If I were satisfied with testing only on standard screen dimensions, rather than being size-agnostic, I probably would have a better time of it too. NoDamage posted:Also, stack views are great and simplify a lot of layout scenarios that used to be much more complicated to set up. From what I've seen they don't really play nicely with manual layout though.
|
|
#
?
Aug 4, 2017 10:05
|
|
|
Doctor w-rw-rw- posted:Debugging a stack trace >40 levels deep into Autolayout wasn't fun for one frame. On every frame? My CPU has better things to do. Apple can open-source Autolayout and then maybe I'd be interested. Autloayout is just another implementation of the Cassowary algorithm, by the by. (The first C++ link there is the page with the academic papers on it)
|
|
#
?
Aug 4, 2017 18:11
|
|
|
I tend to introduce people to auto layout by saying it's a scalpel when most of the time what you need to make a UI is a table saw.
|
|
#
?
Aug 4, 2017 18:37
|
|
|
hackbunny posted:Most seem to involve triggering a sysdiagnose: is the sysdiagnose output easily readable or it's just meant to be sent to Apple? Because I remember BlackBerry 10 had something like that, but the diagnostic output file was completely unreadable and apparently encrypted Yeah I wasn't optimistic. To be honest I've never looked at sysdiagnose output just passed them on to apple.
|
|
#
?
Aug 4, 2017 19:17
|
|
|
I don't suppose there are any Metal developers in here that can help me figure out why MTKMesh.vertexBuffer.buffer.contents() comes out differently on iOS 9 and iOS 10? Here's a project demonstrating the problem: https://github.com/bitshapesoft/ModelIOVertexBufferContents
|
|
#
?
Aug 4, 2017 21:53
|
|
|
I'm using Metal in one of my games, but it's all done by hand, no MetalKit or ModelIO or anything. Also, I still haven't learned Swift  , so it's in Objective-C.One thing that jumps out: use the Swift equivalents to offsetof() and sizeof() to get the vertex attribute offsets and strides, respectively, instead of hard coding them. And what are the differences? Different buffer size? Different internal layout? Does it all still work? Doc Block fucked around with this message at 01:33 on Aug 5, 2017 |
|
#
?
Aug 5, 2017 01:29
|
|
|
Doc Block posted:I'm using Metal in one of my games, but it's all done by hand, no MetalKit or ModelIO or anything. Also, I still haven't learned Swift Well a big problem with using Swift is that there is no way to get the C++ Metal structs visible on the Swift side. I've had some discussions about this and the honest best practice is: just hard-code-enter the stride of the struct. Anyway that works just fine. My question is: when you load an asset into an MTKMesh using Model I/O, how do you alter vertex data in the model? I need to normalize vertices to my coordinate system, change vertex colors, etc.. SO, when you grab the vertex buffer contents, you should just get back a pointer to an array of data arranged like your vertexDescriptor. This is exactly what you get in iOS 9. In iOS 10, when you grab the vertex buffer contents, some models data is just jumbled garbage, and I don't know why. TBH, I'm probably going to use one of my code assist tickets at this point because this is really critical to my app.
|
|
#
?
Aug 7, 2017 16:27
|
|
|
Seems like a bug then, maybe? Do things still render correctly? Can you skip ModelIO and just hand Metal the vertices yourself? edit: I'm wondering if MetalKit or ModelIO is doing some behind the scenes optimization of your vertex data wrt spacing and alignment. I also wonder if they're meant for directly altering the vertex data, or if they expect you to do some OpenGL-like bindBuffer/mapBuffer dance to read/write your vertices. Doc Block fucked around with this message at 18:56 on Aug 7, 2017 |
|
#
?
Aug 7, 2017 18:47
|
|
|
That's my real question: how does one access vertex data? I thought it was direct access to the vertexBuffer.buffer.contents(), and it's not marked as private anywhere. I don't see anything else in the docs... I'd really rather not have to write my own model parser :/
|
|
#
?
Aug 7, 2017 19:53
|
|
|
You don't happen to have a copy of iOS 11 preview running yet that you could run the test project, do you Doc?
|
|
#
?
Aug 7, 2017 19:54
|
|
|
I'm being punished by the UIKit gods for defending auto layout and storyboards in this thread. I have two constraints for a view, one that positions it on screen and one that positions it off screen. I activate one at a time, deactivating the other. For some reason, when the device is rotated, on iPhones only, those constraints are setting their own active flags to how they started in the storyboard. I subclassed NSLayoutConstraint to intercept calls to setActive. setActive is called in my code when I set the correct values but not when the constraints magically reset themselves on device rotation. This does not happen on iPad, so I have a feeling it has something to do with the size class witchcraft. I don't see any size rules in the storyboard, but I have also never used that feature, so I may be missing it. I have absolutely no idea how to troubleshoot this. My best answer so far is to reset the constraints' active flags to their intended values in viewDidLayoutSubviews. That's awful, but I have no idea where UIKit is molesting these constraints. It's hard to imagine this problem in a layout done in code  edit: I found my answer here. It came down to the difference between 'installed' constraints in storyboards vs 'active' constraints in code. I read that those are identical, since only one exists in code and in storyboards, but apparently using an uninstalled constraint instead of an inactive constraint causes the above spooky storyboard adventures. I've also decided that Spooky Storyboard Adventures will be the title of my autobiography. ManicJason fucked around with this message at 00:18 on Aug 8, 2017 |
|
#
?
Aug 8, 2017 00:03
|
|
|
lord funk posted:You don't happen to have a copy of iOS 11 preview running yet that you could run the test project, do you Doc? I do. On my iPhone 6, but yes. PM me if you'd like me to test it. Doc Block fucked around with this message at 00:45 on Aug 8, 2017 |
|
#
?
Aug 8, 2017 00:28
|
|
|
Doc Block posted:I do. On my iPhone 6, but yes. PM me if you'd like me to test it. Thanks, I'll let you know. I put in a ticket about the whole thing so if they throw it back that 'oh that's a bug' then I want to see if it was fixed in 11.
|
|
#
?
Aug 8, 2017 01:04
|
|
|
ManicJason posted:I have absolutely no idea how to troubleshoot this. My best answer so far is to reset the constraints' active flags to their intended values in viewDidLayoutSubviews. That's awful, but I have no idea where UIKit is molesting these constraints. Glad you found a fix. also, lol
|
|
#
?
Aug 8, 2017 04:07
|
|
|
That storyboard installed versus active constraint thing sounds incredibly familiar, pretty sure I've stumbled through same fun you just did. Confusing af.
|
|
#
?
Aug 8, 2017 04:33
|
|
|
I remember when I read that active == installed, because it felt wrong. I went along with it since there is no way to make a constraint inactive in a storyboard otherwise. There is still some subtlety to installing, activating, and adding constraints to views that is not immediately obvious to me, especially once size classes are involved. My choices for the fix were to define them in code or to define them with non-1000 priorities in the storyboard so that they can coexist together there. I did the latter because I am bad at learning lessons.
|
|
#
?
Aug 8, 2017 19:12
|
|
|
I think I tried once to fiddle with size class-specific constraints in code and it ended in tears.
|
|
#
?
Aug 8, 2017 22:05
|
|
|
|
| # ? May 15, 2024 04:17 |
|
|
Doc Block posted:Seems like a bug then, maybe? Haven't heard back yet but signs point to bug. Looks like OBJ files are messed up but STL works fine? If this is really the case, between Swift changes, iOS 10, and this bug, I've been set back only about 4 months.
|
|
#
?
Aug 9, 2017 00:45
|
|