|
code:
|
#
?
Feb 13, 2014 18:39
|
|
|
|
| # ? Jun 7, 2024 00:09 |
|
|
Plorkyeran posted:
There's some weird interactions between lldb and categories. I don't know what the issue is, but it makes it harder to actually use categories in your own code. Lots of system frameworks use categories to organize things, such as NSArray putting core methods in the interface then adding conveniences in a separate category. But with lldb oddities like the above, you're better off just slamming it all together in the interface. I guess I should radar it up but it feels like such a weak bug report. "This sucks and I have no idea what to do about it."
|
|
#
?
Feb 13, 2014 23:35
|
|
|
DWARF doesn't have information about system methods (because that would be a massive amount of information), and the debugger tries to compensate by trawling the runtime metadata, but it isn't always successful. If you can identify a case where it specifically works when a method is declared in the primary interface but not when it's declared in a category, that's worth a radar.
|
|
#
?
Feb 14, 2014 06:03
|
|
|
I'm sorry if this is a retarded question but is there an (efficient) way to develop an iPhone app using a PC? I want to try writing some code in spare time and "for fun" but XCode appears to run only on Macs and I don't want to spend +1K on a 4th computer that I'll probably never use for anything else. Thanks.
|
|
#
?
Feb 14, 2014 20:16
|
|
|
Unexpected posted:I'm sorry if this is a retarded question but is there an (efficient) way to develop an iPhone app using a PC? I want to try writing some code in spare time and "for fun" but XCode appears to run only on Macs and I don't want to spend +1K on a 4th computer that I'll probably never use for anything else. Use a mac mini if you want to go cheap.
|
|
#
?
Feb 14, 2014 20:23
|
|
|
Bah. Thank you.
|
|
#
?
Feb 14, 2014 20:30
|
|
|
Unexpected posted:Bah. Thank you. Side note since I saw you posting in the Android thread: Android is free, but it's also a significantly worse platform to release apps on. Even forgetting any language qualms about Java vs. Objective-C, Android's APIs are significantly more awkward or convoluted, and there are a *lot* more unpleasant hidden surprises on Android. To top it all off, its apps are way less profitable.
|
|
#
?
Feb 14, 2014 20:51
|
|
|
Doctor w-rw-rw- posted:Side note since I saw you posting in the Android thread: Android is free, but it's also a significantly worse platform to release apps on. Even forgetting any language qualms about Java vs. Objective-C, Android's APIs are significantly more awkward or convoluted, and there are a *lot* more unpleasant hidden surprises on Android. To top it all off, its apps are way less profitable. This. Having done both - iOS is about 487.76 times easier to develop/release for. I arrived at that number via SCIENCE. Seriously, tho. People balk about how Apple has all their poo poo locked down and I can't customize this or that and blah blah. Dude - it's a developer's WET DREAM, tho. Very limited number of devices/screens. Very limited number of OS version to support - and even if you do only want to support the latest, the adoption rate for new iOS releases is crazy high - like 87% or some poo poo. So you're not even missing that many people if they didn't upgrade. For Android there is basically NO WAY you can support everyone and everything. Every hardware manufacturer has their own version of the OS, the Android emulator is SLOW AS poo poo, (tho there is an alternative, I've heard). Screen resolutions are all over the place. It's nutty. If the screen layout manager was anywhere NEAR as smart as iOS's it would be kind of okay, but as it stands - you finally get one screen looking good at one resolution, then you either flip the device, or pull it up it up on an emu with a different resolution and everything is hosed. Go iOS. It's like WAY better.
|
|
#
?
Feb 14, 2014 21:28
|
|
|
Plus, if you have even moderate success on the App Store that mini will quickly pay for itself.
|
|
#
?
Feb 14, 2014 21:32
|
|
|
Thank you all. Really appreciate it.
|
|
#
?
Feb 14, 2014 23:27
|
|
|
HaB posted:For Android there is basically NO WAY you can support everyone and everything. Every hardware manufacturer has their own version of the OS, the Android emulator is SLOW AS poo poo, (tho there is an alternative, I've heard). Screen resolutions are all over the place. It's nutty. If the screen layout manager was anywhere NEAR as smart as iOS's it would be kind of okay, but as it stands - you finally get one screen looking good at one resolution, then you either flip the device, or pull it up it up on an emu with a different resolution and everything is hosed. Unless you're counting forks like Kindle Fire, the official APIs for the API level are identical (manufacturers have to guarantee this to get Google's sign off). You have a point about adoption, but at this point you can probably just target Jellybean or above. The emulator is indeed slow, because it's an actual emulator, not a simulator. Use an x86 image with GL hardware support and it gets a lot better. There are indeed a lot of screen resolutions, but there are dramatically better tools for this on android since they've basically designed for this from the start. If you try to do pixel perfect on android you're going to have a bad time, but if you do relative layouts intelligently everything is fine, and the tools can show you the most common resolutions simultaneously as you edit so that you know you're not overlooking anything. Honestly, you can complain just as much about flipping the screen for iOS as you can for android, it's a silly argument. Developing for Android has its advantages and disadvantages, same as developing for iOS. If you're finding Android development to be THAT hard, ask for help; I assure you that it's not.
|
|
#
?
Feb 15, 2014 00:26
|
|
|
One more question. Sorry! Is using Xcode feasible on a laptop? E.g. this one: 13-inch: 2.4GHz with Retina display 2.4GHz dual-core Intel Core i5 Turbo Boost up to 2.9GHz 8GB 1600MHz memory 256GB PCIe-based flash storage1 Intel Iris Graphics Or is a "desktop" the way to go?
|
|
#
?
Feb 15, 2014 01:54
|
|
|
Volmarias posted:Unless you're counting forks like Kindle Fire, the official APIs for the API level are identical (manufacturers have to guarantee this to get Google's sign off). You have a point about adoption, but at this point you can probably just target Jellybean or above. I've written Android apps for phones and tablets with millions of downloads, I had preview access to GoogleTV, and I maintained a high rating for the apps, to my knowledge without any kind of rating 'juicing' to bias ratings towards people already favorably inclined to rate high. I was on the Paper team working on some of the most complex iOS code around. So, disclaimer: I am in a good position to compare and contrast the platforms at an advanced level. I wrote about this a couple of years back, but Android is a shitshow of APIs that only do 90% of what they need to, and break horribly if you violate their expectations. The essential APIs (for example the Fragments API) are often subtly broken in ways that aren't obvious until you've overcommitted to them, i.e. using the Fragment backstack only to find out that its state restoration is totally hosed because Google couldn't be arsed to do a good job and fill in holes in their abstractions, preferring instead to leak details. The different handset makers do lovely customizations, for example closing cursors in finalize() (Motorola), removing an Android-default theme (HTC, way back when), lying about their screen size to gently caress with app appearances (Samsung), or lying about their video decoder stack in a way that totally breaks video playback on a lot of lower-end devices (Samsung, again). The only recourse being to run a HTTP server and actually sniff the user-agent string if you really want to know what video decoder you're using. Android has had only a couple of years to "design for this from the start". To argue that iOS can't be that much more mature is to totally miss out on the fact that UIKit is a cleaned-up framework based on 30+ years of very mature work on NeXTSTEP and then on OS X regarding layouts. Android literally destroys and re-creates and restores activities on screen rotation, unless you disable it. Besides being horrible for animation, this is braindead in that you desperately need reliable state restoration if you have anything more complex than a bunch of default controls. Which, by the way, Google broke in the 2.x series because they realized that one of the state-saving functions was not deterministically called thanks to a race condition. I've developed on iOS from 3.0-7.0 and on Android from API 7 (2.1) through API 16 (4.1). iOS lets its developers grow into more advanced manipulations of its rich set of classes for views, animations, and other tools for building apps. The more stable the Android app, the more devices it supports, and the more dynamic the interface, the more and more Android fails to rise to the situation and the more you're forced to either reimplement yourself, and the more behavior you may be forced to just *live with*. I've done Android. I have been there. Technically, at this point, I have spent more of my career on Android than iOS, but only just. I am, as far as I can tell, pretty good at learning things and diving into them without calling them poo poo beforehand. For all of their advantages and disadvantages, bugs or special features, comparing the two platforms to each other from a developer point of view, Android is not awesome. iOS is way powerful. And personally, a heck of a lot more fun. Unexpected posted:One more question. Sorry! Doctor w-rw-rw- fucked around with this message at 01:58 on Feb 15, 2014 |
|
#
?
Feb 15, 2014 01:54
|
|
|
Going minSdkVersion=14 on Android is totally the way to go these days and alleviates most of these issues. Dynamic layouts and handling different screen sizes is now a breeze in the Android world. That said the iOS SDK is still easier to wrap ones head around, the Android lifecycle is pretty annoying to deal with (hence projects like Mortar/Flow from Square). But really it's not very different from iOS. Both are fun, play with both if you can - otherwise just sticking to whatever PC you have now and doing Android is fine. Just don't jump into the hell that is Android <= 2.2 Glimm fucked around with this message at 02:13 on Feb 15, 2014 |
|
#
?
Feb 15, 2014 02:11
|
|
|
Unexpected posted:One more question. Sorry! I was running XCode on a bottom-line MacBook White from 2008 up until Mavericks hit, so I suspect you'll be fine.
|
|
#
?
Feb 15, 2014 02:35
|
|
|
Doctor w-rw-rw- posted:To top it all off, its apps are way less profitable. Every once in a while someone posts a new article about how Android revenues are closing the gap to iOS. While that may technically be true in aggregate, it's mostly because of free-with-IAP games at the top end (Candy Crush, Clash of Clans, etc) heavily skewing the numbers. But for the average developer there is much more profit to be had on iOS across the board, whether that is paid, IAP, or ad-supported.
|
|
#
?
Feb 15, 2014 02:57
|
|
|
The Hackintosh thread might be able to help you get OS X running on one of the computers you already have.
|
|
#
?
Feb 15, 2014 03:13
|
|
|
I'll point out that while everything 666 said may be true at some level, at others it's completely moot. I have a top 50 highest grossing freemium game on both ios and android built from the same code base including ui. When your interaction with ios or android is "Here draw this on the Gl surface" the platforms are close to identical.
|
|
#
?
Feb 15, 2014 03:46
|
|
|
Hughlander posted:I'll point out that while everything 666 said may be true at some level, at others it's completely moot. I have a top 50 highest grossing freemium game on both ios and android built from the same code base including ui. When your interaction with ios or android is "Here draw this on the Gl surface" the platforms are close to identical. This is true. I speak mostly of the included UI toolkits. Games are largely a separate market, set of programming APIs, technical considerations, and business models. If you are writing a game, you are writing against a lower-level API that is available and for the most part consistent across devices. In that sense, Android will likely not be so different, but games are their own universe.
|
|
#
?
Feb 15, 2014 04:58
|
|
|
Doctor w-rw-rw- posted:This is true. I speak mostly of the included UI toolkits. Games are largely a separate market, set of programming APIs, technical considerations, and business models. If you are writing a game, you are writing against a lower-level API that is available and for the most part consistent across devices. In that sense, Android will likely not be so different, but games are their own universe. The drawback of that freedom from complexity is that you usually can't use the system's layout tools on either platform and have to roll your own (or punt and just scale everything).
|
|
#
?
Feb 15, 2014 05:03
|
|
|
I started on an effortpost, but I realized that it's just going to turn into a flamewar and neither of us will change our minds, so I'll just say that I'm looking forward to learning more about iOS and hopefully some of the eccentricities that I've noticed about the platform and development environment start to make more sense.
|
|
#
?
Feb 15, 2014 05:22
|
|
|
Volmarias posted:I started on an effortpost, but I realized that it's just going to turn into a flamewar and neither of us will change our minds, so I'll just say that I'm looking forward to learning more about iOS and hopefully some of the eccentricities that I've noticed about the platform and development environment start to make more sense. I encourage you to make the effortpost anyways so that we can inform our opinions better. Or question the eccentricities of iOS, so we can verify or explain or offer workarounds for those issues.
|
|
#
?
Feb 15, 2014 05:27
|
|
|
Oh man your rants in the Android thread were the absolute best. I got to read them just as we were working out what to do about and Android port. Edit: I mean really everyone should check out Dr. 666's venting.
|
|
#
?
Feb 15, 2014 05:46
|
|
|
For reference, here are some excerpts - While explaining the progression of an Android workflow involving many libraries: Doctor w-rw-rw- posted:* This journey of one and a half years slowly drives you mad, culminating in desperate cries for sympathy in the technical section of an online forum with people likely to understand your pain. Doctor w-rw-rw- posted:Extreme bitterness, I'll be the first to admit that I am biased against Android: It, along with a monumental rear end in a top hat of a manager (who recommended I quit because of my work-related depression at the time), triggered a nervous breakdown on my part that ended in me leaving a job and a company that I otherwise loved (which didn't actually intend to let me go, but did so accidentally). Thankfully, I reinvested my time in iOS and in time, recovered completely. That said, Android is also obviously important and better than everything else it killed and took the place of. ...It's just that everything in my personal experience, and in all of my talks with other professionals in the industry, the best people on iOS get to be passionate about writing apps. The best people on Android...basically end up doing what I did and patch over deficiencies in the platform. It's annoying because it gets in the way of progress, even if nothing is truly impossible. I have never been able to find a competent professional Android developer who loved Android the way iOS pros love iOS, and not for lack of trying. The people who make magic happen, even if they are on both platforms, tend heavily towards iOS rather than Android. --- Anyways, in Apple developer-related news, it turns out it's possible to script Xcode project creation in Python by loading in some of Xcode's frameworks. If you class-dump the headers and spend some time figuring out the right incantations to call, you can actually programmatically create and/or manipulate Xcode projects. I'm almost done reverse-engineering the process to create an application, and thereafter it should be pretty simple for others to figure out how to extrapolate from there. Anyone else have a use for this? A small sample: Python code:Doctor w-rw-rw- fucked around with this message at 07:00 on Feb 15, 2014 |
|
#
?
Feb 15, 2014 06:56
|
|
into 
, and 
below.
, you say? Okay, well...
|
Doctor w-rw-rw- posted:Anyways, in Apple developer-related news, it turns out it's possible to script Xcode project creation in Python by loading in some of Xcode's frameworks. If you class-dump the headers and spend some time figuring out the right incantations to call, you can actually programmatically create and/or manipulate Xcode projects. I'm almost done reverse-engineering the process to create an application, and thereafter it should be pretty simple for others to figure out how to extrapolate from there. Looks a lot like what xctool does, so I guess someone has a use for it 
|
|
#
?
Feb 15, 2014 07:30
|
|
|
pokeyman posted:Looks a lot like what xctool does, so I guess someone has a use for it Nope, xctool is for running and testing - not for synthesizing new projects. My use case is to take a xcdatamodel file and a configuration file to create a library project (with all of the generated sources) that can just be dropped in to other projects.
|
|
#
?
Feb 15, 2014 07:39
|
|
|
Doctor w-rw-rw- posted:Nope, xctool is for running and testing - not for synthesizing new projects. My use case is to take a xcdatamodel file and a configuration file to create a library project (with all of the generated sources) that can just be dropped in to other projects. Sorry, I meant to say similar to xctool's implementation: load Xcode's frameworks and call methods you find therein. Sounds like you're making mogenerator taken to its logical endpoint.
|
|
#
?
Feb 15, 2014 09:33
|
|
|
Doctor w-rw-rw- posted:I'll be the first to admit that I am biased against Android: It, along with a monumental rear end in a top hat of a manager (who recommended I quit because of my work-related depression at the time), triggered a nervous breakdown on my part that ended in me leaving a job and a company that I otherwise loved (which didn't actually intend to let me go, but did so accidentally). Thankfully, I reinvested my time in iOS and in time, recovered completely. I'll say outright ; that really isn't healthy. If you become so obsessed over a job with a platform that you have a mental breakdown and your recovery is to go just as deep in another platform it's not really a recovery. Doctor w-rw-rw- posted:
We use premake on a project that basically does this but with Lua. The xcodeproj is built from scratch each time the CI machine touches it or an engineer checks it out. I know that I've been thinking of rebuilding an xcodeproj file after xctool insists that it has a dependency on a workspace called 'Tests' that: a) doesn't exist. b) I can't find in the proj file c) that xcodebuild doesn't think exists and can build the project just fine.
|
|
#
?
Feb 15, 2014 15:30
|
|
|
Hughlander posted:I'll say outright ; that really isn't healthy. If you become so obsessed over a job with a platform that you have a mental breakdown and your recovery is to go just as deep in another platform it's not really a recovery. Hughlander posted:We use premake on a project that basically does this but with Lua. The xcodeproj is built from scratch each time the CI machine touches it or an engineer checks it out. I know that I've been thinking of rebuilding an xcodeproj file after xctool insists that it has a dependency on a workspace called 'Tests' that: Doctor w-rw-rw- fucked around with this message at 17:36 on Feb 15, 2014 |
|
#
?
Feb 15, 2014 17:33
|
|
|
Volmarias posted:Unless you're counting forks like Kindle Fire, the official APIs for the API level are identical (manufacturers have to guarantee this to get Google's sign off). You have a point about adoption, but at this point you can probably just target Jellybean or above. I don't find it "hard" - but it's a LOT more effort to get something up and running on Android than it is on iOS, and my main language for YEARS was C# - which has WAY more in common with Java than it does with Obj-C. Even installing the Android SDK on a completely fresh Windows install didn't go well and took some fiddling to get it to work at all. Poking around message boards found a lot of similar problems other people were having. Java is a known bloatfest and has been for years. The Apple SDK is slick and polished and for the most part "poo poo just works". But - starting as a 15+ years experienced programmer having never done any mobile development at all - in spite of the massive syntax differences between C# and Obj-C - the time from jump-in to basic app up and running on the device and working properly was WAY shorter on iOS. So I agree to a point - there are pros and cons to both - but for my situation, it was almost no contest.
|
|
#
?
Feb 15, 2014 17:53
|
|
|
Deleting the xcsheme and recreating it 'fixed' the issue. Which is odd since the diff in git looks like: code: Now to figure out why OCLint doesn't want to pick up the system C++ paths and complains about not being able to compile a file because I #include <string>
|
|
#
?
Feb 15, 2014 18:00
|
|
|
So I found an issue that I'm wondering the technical reason behind. I have some JSON data coming back from an API. One of the KeyValue pairs is "id": 1. So once I've parsed the JSON into a dictionary, I'm making the following call in a data object: code:code:During debug, I see that the dictionary value for the key "id" was a type long of 1. I thought that the type cast (int) on a long would convert it to 1 just fine, 311 seems weird? I solved it by using the following code: code:
|
|
#
?
Feb 15, 2014 18:38
|
|
|
Doctor w-rw-rw- posted:I encourage you to make the effortpost anyways so that we can inform our opinions better. Or question the eccentricities of iOS, so we can verify or explain or offer workarounds for those issues. I'm going to just leave the Android parts alone; better for those to be discussed in the Android thread, and I don't have the time for an effortpost at this point. As far as iOS goes, I'll start out with saying that my understanding is that nib files are, shall we say, OPAQUE in their underlying structure, meaning that two developers modifying the same layout may have significant trouble merging those changes. Doctor w-rw-rw- posted:I started out on iOS, got pretty deep, then switched jobs - got hired for iOS at that job - and was promptly forced onto Android for two years. My recovery from the Android job was having a boss and a mentor that actually helped me with my mental health rather than shaming me weekly for not delivering something that was impossible given the timeframe, sometimes in front of others. I strongly associated Android with stress - a lot of that also caused by the sheer difficulty of meeting a high bar of quality - but now I just have a distaste for it and I strive to frame my reasons rationally. So it wasn't so much a response as a return - I knew what I really wanted and I wasn't allowed to pursue it because I had gotten good at something else. Yeah, I think that part of it is just associating Android with a truly awful experience, where you probably didn't get encouragement and you didn't get exposed to people who really knew and were passionate about the platform. I've worked with some real turkeys in the past (need to clear state in an Activity? Just call finish() in onPause(), what's the problem?  ), and if I had to associate them with Android I'd definitely not want to do it either. I'm fortunate enough to be friends with a few incredibly smart people with skills and passion, along with some of the Android developers, and it's a whole different ballgame when you can just ask the guy who wrote some part why it was done that way. There's usually very good reasons that may not be obvious why some things are done as they are. That said, the source code is always right there, and if you've downloaded it you can just ctrl-click into it and figure out how exactly something works.You're definitely right in a few things that you mention, it's just not quite as dour and hopeless as you put it, and usually there are good workarounds for them (which I won't get into, but you can always ask in the Android thread). HaB posted:I don't find it "hard" - but it's a LOT more effort to get something up and running on Android than it is on iOS, and my main language for YEARS was C# - which has WAY more in common with Java than it does with Obj-C. Even installing the Android SDK on a completely fresh Windows install didn't go well and took some fiddling to get it to work at all. Poking around message boards found a lot of similar problems other people were having. Ignoring the fact that it's easier to do Android development on Windows (and Linux!) in that it's not possible to legitimately do iOS dev on Windows (and Linux!), I'll point out that Windows is probably the worst OS to do Android development on. If you use Linux (preferably Ubuntu), you just apt-get install the necessary components (basically, Java and now Gradle), plug in your phone, extract Android Studio to where you want it, open it, and hit "Run" for the Hello World app. poo poo just works. On windows, you need to dick with device drivers (which have gotten a lot better) etc. Of course, having done Android development since the pre-1.0 preview SDK, I'm probably more used to this. Volmarias fucked around with this message at 18:43 on Feb 15, 2014 |
|
#
?
Feb 15, 2014 18:40
|
|
|
It's wrapping the numbers in NSNumbers, because int is a C type and arrays have to contain NSObject subclasses. If you call NSStringFromClass([[dict objectForKey:@"id"] class]) you can see for yourself.
|
|
#
?
Feb 15, 2014 18:49
|
|
|
FlashBangBob posted:Whats going on under the hood? I'm pretty sure the object you're getting back from the Dictionary is an NSNumber, as the collection classes can't store primitive types. On that basis I'm pretty surprised you got "311" first time round rather than a longer pointer address. Edit: Beaten 
|
|
#
?
Feb 15, 2014 18:53
|
|
|
Froist posted:I'm pretty sure the object you're getting back from the Dictionary is an NSNumber, as the collection classes can't store primitive types. On that basis I'm pretty surprised you got "311" first time round rather than a longer pointer address. NSNumbers below 100 are cached/deduplicated, if memory serves, since they're pretty common. vvv ah, thanks. That would make more sense given the value he posted. Doctor w-rw-rw- fucked around with this message at 19:33 on Feb 15, 2014 |
|
#
?
Feb 15, 2014 19:00
|
|
|
Doctor w-rw-rw- posted:NSNumbers below 100 are cached/deduplicated, if memory serves, since they're pretty common. They're tagged pointers now: https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-build-tagged-pointers.html http://objectivistc.tumblr.com/post/7872364181/tagged-pointers-and-fast-pathed-cfnumber-integers-in
|
|
#
?
Feb 15, 2014 19:25
|
|
|
Doctor w-rw-rw- posted:UIKit is a cleaned-up framework based on 30+ years of very mature work on NeXTSTEP and then on OS X regarding layouts. Counterpoint: UITableView/UITableViewController. Also: don't dare animate anything unless you like state changes being ignored because an animation is already in progress. gently caress animated anything. gently caress animated UITableView x100
|
|
#
?
Feb 15, 2014 20:51
|
|
|
hackbunny posted:Counterpoint: UITableView/UITableViewController. Also: don't dare animate anything unless you like state changes being ignored because an animation is already in progress. gently caress animated anything. gently caress animated UITableView x100
|
|
#
?
Feb 15, 2014 20:56
|
|
|
|
| # ? Jun 7, 2024 00:09 |
|
|
Volmarias posted:As far as iOS goes, I'll start out with saying that my understanding is that nib files are, shall we say, OPAQUE in their underlying structure, meaning that two developers modifying the same layout may have significant trouble merging those changes. I have found it easier just to read the code to see what's going on, and writing the layout code out was easier to keep things matching the comps from our designer since he had redlines with pixel margins written in. Also it was infuriating that just the very act of opening a xib file -- not changing the design -- was enough to change the file. And yeah merging xcode project files within a team was annoying enough at times so the less auto generated magical files to deal with, the better.
|
|
#
?
Feb 15, 2014 22:55
|
|
