|
Just out of curiosity, do they work in browsers on non-apple platforms?
|
#
?
Jun 15, 2015 01:20
|
|
|
|
| # ? May 16, 2024 13:11 |
|
|
UIApplication posted:Just out of curiosity, do they work in browsers on non-apple platforms? No. I think there is a hack you can do with VLC to make it work on windows or Linux. Also, switch to safari, it is really good in Yosemite.
|
|
#
?
Jun 15, 2015 01:24
|
|
|
UIApplication posted:Just out of curiosity, do they work in browsers on non-apple platforms? No. At least not Chrome on Windows 8.1. That's my issue. My main computer is a Windows machine, so if I want to watch these videos I need to get out my Macbook  (Wow, first world problems or what?)
|
|
#
?
Jun 15, 2015 01:28
|
|
|
Dirk Pitt posted:Also, switch to safari, it is really good in Yosemite. It's pretty decent, as long as you don't want WebM or developer tools worth the name.
|
|
#
?
Jun 15, 2015 01:28
|
|
|
Off topic but ditto the switch to safari on Yosemite, I don't even have flash installed. All the must have extensions are there (last pass, ublock etc) and its a major battery life improvement.* *I still keep chrome installed for apps that have no flash, and Google maps performance is a bit sluggish in safari. Kallikrates fucked around with this message at 01:54 on Jun 15, 2015 |
|
#
?
Jun 15, 2015 01:51
|
|
|
status posted:No. At least not Chrome on Windows 8.1. That's my issue. My main computer is a Windows machine, so if I want to watch these videos I need to get out my Macbook
|
|
#
?
Jun 15, 2015 02:16
|
|
|
Plorkyeran posted:You can't even just download them? Well, now I can. 
|
|
#
?
Jun 15, 2015 02:24
|
|
|
Kallikrates posted:Off topic but ditto the switch to safari on Yosemite, I don't even have flash installed. All the must have extensions are there (last pass, ublock etc) and its a major battery life improvement.* I'll second (third? fourth?) this. After reading TheVerge's article on Chrome's impact on battery life and then getting the MacBook, I vowed to make the switch to Safari and haven't installed Flash. Chrome is always there for sites that do need flash video (BBC, small subset of podcasts), but Safari is suiting my needs really well and the few extensions I used all have an equivalent. The only thing I really miss is favicons on the bookmarks bar/tabs. Also thanks for mentioning the Maps issue - it's really laggy on scrolling here, but I thought that was just me/the MacBook and hadn't tried it in Chrome to compare.
|
|
#
?
Jun 15, 2015 07:34
|
|
|
Ok, I have the most basic of basic iOS questions. I want to create a CYOA app, with a layout sort of like: image text branch 1 branch 2 branch 3 MSPaint mockup:  I can get that working in storyboard, fine. I can get this working in the app and load from the database. But having the image, text, and branch 1 or branch 2 resize automatically to fit their content? Well, no. Not and scroll correctly. I've been trying to make this work with autolayout constraints as much as possible, but I'm missing something apparently. A few different approaches come to mind: 1) UIScrollView includes a UIImageView, UITextView, and UITableView. This worked well for a while, but ultimately stalled out. 2) UITableView includes 3 sections, with the first two having a UIImageView and a UITextView respectively. Second idea, which also stalled out. 3) I could do some sort of programmatic calculation and layout the items just inside a view rather than a UIScrollView, but then I have to get a scrolling solution. What's the idiomatic solution to this using iOS 8 and auto-layouts? All the stackoverflow hits seem to have an absurd amount of code to what I would have thought would be a solved problem.
|
|
#
?
Jun 17, 2015 03:41
|
|
|
UIStackView in iOS9? Sigh. Maybe I should throw in the towel on autolayout and adopt it. Apple seems determined to make it useful.
|
|
#
?
Jun 17, 2015 06:21
|
|
|
ulmont posted:What's the idiomatic solution to this using iOS 8 and auto-layouts? All the stackoverflow hits seem to have an absurd amount of code to what I would have thought would be a solved problem. Add a scroll view and pin its edges to the edges of its superview. Add a UIView as the scroll view's sole subview and pin its edges to the scroll view's edges, this will be your content view. Now add your contents – image view, multiline label, buttons – to the content view. Be sure to pin the topmost bit of content to the top of the content view and the bottommost bit of content to the bottom of the content view. Finally, pin the content view's leading and trailing constraints to your view controller view's leading and trailing to force the scroll view to fill the screen width.
|
|
#
?
Jun 17, 2015 12:45
|
|
|
Also, it doesn't seem like adding a table view to a scroll view is the best idea. Seems like one or the other would prevent the other from scrolling.
|
|
#
?
Jun 17, 2015 14:39
|
|
|
pokeyman posted:Add a scroll view and pin its edges to the edges of its superview. Add a UIView as the scroll view's sole subview and pin its edges to the scroll view's edges, this will be your content view. Now add your contents – image view, multiline label, buttons – to the content view. Be sure to pin the topmost bit of content to the top of the content view and the bottommost bit of content to the bottom of the content view. Finally, pin the content view's leading and trailing constraints to your view controller view's leading and trailing to force the scroll view to fill the screen width. Doc Block posted:Also, it doesn't seem like adding a table view to a scroll view is the best idea. Seems like one or the other would prevent the other from scrolling.
|
|
#
?
Jun 17, 2015 15:00
|
|
|
I'm curious why the approach of using a sectioned table view with the image view as section 0, the text view as section 1, and the remaining cells as section 2, stalled out? That seems like the right approach here if you want one contiguous scrolling region.
|
|
#
?
Jun 17, 2015 15:14
|
|
|
Doctor w-rw-rw- posted:Sigh. Maybe I should throw in the towel on autolayout and adopt it. Apple seems determined to make it useful. In Swift-land, Cartography was enough to get me to play with autolayout. Prior to that, I was doing all frame-based layout, though. To a certain extent, they're both about defining the numerical relationships between things; in frame-based layout, you're doing the math yourself, whereas in autolayout you're telling the system what your relationships are and letting the system do the math for you. Frame-based is more performant, but more prone to manual errors, not to mention probably being harder to read; autolayout, especially with the new functions, gives you more clear definition of what you want at the cost of performance and ease of debugging. Or you can use IB, though I'm still not convinced that it's a better way of doing layouts.
|
|
#
?
Jun 17, 2015 15:19
|
|
|
Flobbster posted:I'm curious why the approach of using a sectioned table view with the image view as section 0, the text view as section 1, and the remaining cells as section 2, stalled out? That seems like the right approach here if you want one contiguous scrolling region. If I'm going to have to trigger the resizing in code, that's easier with the scroll view model.
|
|
#
?
Jun 17, 2015 15:29
|
|
|
ulmont posted:That's what my original approach was. It works fine for the top image and the text view in the middle. It doesn't seem to work for the table view at the bottom. Ah, I missed that you had a table view at the bottom. I think your options at this point are to either stick a height constraint on the table view and set it to the table's contentSize.height in code, or move everything to a table view and use the auto sizing table view cells new to iOS 8.
|
|
#
?
Jun 17, 2015 17:10
|
|
|
Axiem posted:In Swift-land, Cartography was enough to get me to play with autolayout.  Okay, that's pretty cool. Down the rabbit hole I go.
|
|
#
?
Jun 17, 2015 18:25
|
|
|
What the? How does that even work? It looks cool.
|
|
#
?
Jun 17, 2015 18:41
|
|
|
It's just extensions and proxy objects with judicious use of operator overloading. It's definitely the bee's knees though; I swear by it in a couple of my personal projects.
|
|
#
?
Jun 17, 2015 19:44
|
|
|
Wow, that might get me off of IB. The layout(view1, view2, view3) { view1, view2, view3 in stuff is kind of gross though. I guess you could just use $1, $2, $3. Dessert Rose fucked around with this message at 19:52 on Jun 17, 2015 |
|
#
?
Jun 17, 2015 19:50
|
|
|
You all better post trip reports. I don't see how much longer we can realistically avoid auto layout but I ain't going into IB. Also I don't want to jinx it, but the Xcode 7 beta has been pretty stable over a few days of work.
|
|
#
?
Jun 17, 2015 23:46
|
|
|
It's been basically as stable as 6.3 for me.
|
|
#
?
Jun 17, 2015 23:56
|
|
|
lord funk posted:You all better post trip reports. I don't see how much longer we can realistically avoid auto layout but I ain't going into IB. If you're comfortable doing springs and struts/setFrame: sans-IB then I can't see auto layout giving you any trouble. Third-party libraries and/or iOS 9 can make it even better, but it's not an order of magnitude difference. In a related matter, Xcode 7 exposes constraint identifiers in IB so that'll make constraints a lot less write-only.
|
|
#
?
Jun 18, 2015 02:58
|
|
|
You can create IBOutlets for constraints in IB and modify them... I really don't understand the IB/AutoLayout hate in this thread.
|
|
#
?
Jun 18, 2015 13:14
|
|
|
Meat Street posted:You can create IBOutlets for constraints in IB and modify them... I really don't understand the IB/AutoLayout hate in this thread. I used to be staunchly opposed to it until I started my new job 5 months ago. Then I started using it and it's p good. Using IB and Autolayout is fantastic with storyboards and laying out simple content. Building out prototype cells in UITableViews and UICollectionViews is slick as hell AS LONG AS you aren't doing anything super complex in them. Once that happens and and we hit performance issues, then we start rolling into manual layout as it seems to be the way to go. Doh004 fucked around with this message at 15:12 on Jun 18, 2015 |
|
#
?
Jun 18, 2015 15:04
|
|
|
Meat Street posted:You can create IBOutlets for constraints in IB and modify them... I really don't understand the IB/AutoLayout hate in this thread. A rocky start with buggy / un-resolvable constraint scenarios, poor performance, and having it shoved down our throats? I totally see the benefit of Autolayout, but a few false starts in trying to adopt it made me hate my life. I think IB is fine, but I don't make the kind of apps where dropping in a few textfields and buttons is sufficient. At a certain point with more dynamic layouts it doubles the work to have to figure out where some layout action is being set.
|
|
#
?
Jun 18, 2015 15:04
|
|
|
It's certainly not the best tool for the job in all cases, and I definitely lay out custom views manually beyond a certain threshold of complexity. I just don't think people are doing themselves any favors by ignoring IB entirely; I realize it had a rocky start when AutoLayout dropped but these days it's the right tool for most jobs.
|
|
#
?
Jun 18, 2015 15:10
|
|
|
I've found that purely adopting one thing over the other isn't the greatest approach. We do a mix of everything (storyboard/xib/autolayout/manual frame jiggling) where it makes sense and have a lot less headaches overall. There are definitely cases to be made for everything and no one solution will cover all bases.
|
|
#
?
Jun 18, 2015 15:54
|
|
|
Any word as to the behavior of the iPad multitask mode for apps that don't use 100% autolayout? I wonder if itll just check for autoresize masks at build time and set some ineligible flag, or if it'll have some scaling/compatibility mode like when you run iPhone apps on an iPad.
|
|
#
?
Jun 18, 2015 16:34
|
|
|
UIApplication posted:Any word as to the behavior of the iPad multitask mode for apps that don't use 100% autolayout? I wonder if itll just check for autoresize masks at build time and set some ineligible flag, or if it'll have some scaling/compatibility mode like when you run iPhone apps on an iPad. So long as you use your window/view bounds (instead of hard coding widths) and you implement the trait collection change callbacks, there's no reason you couldn't handle iPad split view perfectly without so much as a single constraint. Autoresize masks are indeed translated into constraints when appropriate, but that's a completely separate and probably irrelevant matter.
|
|
#
?
Jun 18, 2015 16:44
|
|
|
pokeyman posted:So long as you use your window/view bounds (instead of hard coding widths) and you implement the trait collection change callbacks, there's no reason you couldn't handle iPad split view perfectly without so much as a single constraint. It kind of struck me as a way for apple to force everyone to adopt AL. Like I said, they could easily give us some scaling solution, but it struck me as something they could realistically (given their track record) choose not to do.
|
|
#
?
Jun 18, 2015 17:45
|
|
|
UIApplication posted:It kind of struck me as a way for apple to force everyone to adopt AL. Like I said, they could easily give us some scaling solution, but it struck me as something they could realistically (given their track record) choose not to do. I think the message is "adopt auto layout for best effect" but there is nothing in the implementation of these features that requires it or could somehow punish you for not using auto layout. So far as I can tell anyway. Even new stuff like readableContentGuide is perfectly usable in code without auto layout. I'm not sure what you mean by "scaling solution".
|
|
#
?
Jun 18, 2015 18:25
|
|
|
pokeyman posted:I'm not sure what you mean by "scaling solution". Just render it as fullscreen portrait, rotate it, scale it down
|
|
#
?
Jun 19, 2015 05:11
|
|
|
UIApplication posted:Any word as to the behavior of the iPad multitask mode for apps that don't use 100% autolayout? I wonder if itll just check for autoresize masks at build time and set some ineligible flag, or if it'll have some scaling/compatibility mode like when you run iPhone apps on an iPad. Our app at work is mostly fine in the split view and we don't use auto layout at all. We were also fine last year scaling to the 6/6+ sizes without any changes. The only part we really break on is running in 1/3 screen space on the right, as our iPad layout just won't scale that small. I need to look into a way of switching to the iPhone layout without having to adopt the size classes introduced last year, but we have higher/less fun priorities right now Has anyone else seen issues with UIAlertViews (without using UIAlertViewController) in the split layout? Ours show centered relative to the screen rather than our window, so at a 50/50 split the "OK" button is unreachable. Maybe we need to adopt the UIAlertViewController, but we're still supporting iOS 5 so I guess it would need to be conditional.
|
|
#
?
Jun 19, 2015 10:05
|
|
|
Yay app release day! http://www.bitshapesoftware.com/instruments/tc-performer/ TC-Performer. Free synth, universal, patch pack IAP.
|
|
#
?
Jun 19, 2015 15:08
|
|
|
Froist posted:Has anyone else seen issues with UIAlertViews (without using UIAlertViewController) in the split layout? Ours show centered relative to the screen rather than our window, so at a 50/50 split the "OK" button is unreachable. Maybe we need to adopt the UIAlertViewController, but we're still supporting iOS 5 so I guess it would need to be conditional. I've seen this happen with system apps, so I assume it's just a bug that will be fixed.
|
|
#
?
Jun 19, 2015 17:42
|
|
|
Old style alertview presentation uses UIAlertViewController under the hood anyway.
|
|
#
?
Jun 19, 2015 19:57
|
|
|
Does Reachability behave differently when using a build in debug mode or something? I'm adding in connectivity loss in our application and testing it out with the network link conditioner or airplane mode and the reporting of whether I have connectivity barely ever works. I listen in to the reachableBlock and unreachableBlock like I should, as well as check for connectivity if my request fails at all, but manually checking doesn't seem to report it properly. For example, I'll set the link conditioner to 100% packet loss, have a request fail and then check my status: code:
|
|
#
?
Jun 22, 2015 18:25
|
|
|
|
| # ? May 16, 2024 13:11 |
|
|
Reachability is not remotely reliable in any way.
|
|
#
?
Jun 22, 2015 18:33
|
|