Improved old window handling, depreciation warning suppression..

[JonasGessner]

Improved old window handling, added depreciation warning suppression and cancelled state detection.

[larsacus]

Were you seeing some issues with some of this code, or did you just feel like changing it? A lot of these changes don't relate to one another. Just looking for your thoughts before I dive into this.

[JonasGessner]

The code that selects oldWindow didn't work for me in some cases. With a UIAlertView or a GKPeerPickerController or anything else that changes the root view controller that code didn't work out well. Thats why I replaced that. Then oldWindow doesn't need a strong reference but just a weak one.

I added the cancelled BOOL to MMProgressHUD because In a case where I am using it I need to check directly on the HUD whether or not it is cancelled and will be dismissed so I added that BOOL which comes in really handy.

I am also using a custom radial progress view (which is not included in my commit) so to use that with MMProgressHUD it came in handy to use a protocol to allow different types of radial progress views.

typeof() doesn't even compile when I try to so I replaced it with __typeof().

And lastly I suppressed compiler warning about depreciation which were quite annoying ;)

I know they don't really relate to another but I use this in one of my projects so I went through the code to fix and tweak some things :)

[larsacus]

What kind of compiler flags are you using that typeof() doesn't work?

[larsacus]

Let me know if the typeof() compiler thing is happening only on the new Xcode beta.

[JonasGessner]

My bad, I was testing the code In some project I had downloaded from the internet :P Turns out the C Language Dialect was set to C99 and setting it back to "Compiler Default" fixed everything! Sorry!
Should I change it back to typeof() and send a new pull request or do you want to change it back after pulling the commit?

[larsacus]

I'm running the beta and am having some mixed results with typeof() vs __typeof(). Not sure if some default compiler setting changed, but I'm looking into that bit. If you want to do some investigation as well, that would help.

[JonasGessner]

I'm using Xcode 5 DP 5 and I just tried using typeof(), __typeof()and __typeof__() in a fresh project and I get no errors at all. If it doesn't work for you then it might be the C Language Dialect in the target build settings or "Allow 'asm', 'inline', 'typeof'" is turned off in the build settings.

[JonasGessner]

Hmm, I'm building a binary with the Xcode cli right now and here is get the error with typeof() again. __typeof() works just fine tho. We should just use __typeof() as they are all (typeof(), __typeof(), and __typeof__()) identical in what they do and __typeof() seems to be just more reliable than typeof().

[larsacus]

Yeah looks like this specific project's C-language dialect was explicitly set to C99. Changing to compiler default makes it compile properly using all methods. Let's just leave it at __typeof().

Never run into that issue before with typeof().

[larsacus]

What is the purpose of this new boolean? If you want to know when the action was "cancelled", then you would use the cancelBlock block. In addition, it appears that self.cancelled is never explicitly reset to NO anywhere. Unless you can describe a situation in which you think this is useful, I'd rather not add a new property to the public header that duplicates functionality.

[JonasGessner]

Oops yeah I never reset it! My bad! I was using an individual instance rather than the shared Instance so I didn't need to reset the value to NO as I release the instance after dismissing it.
The cancelBlock is very different tho! The cancelBlock is simply called when the user has cancelled the HUD. The HUD will stay visible after that until its dismissed and therefore I needed a way to check of the HUD has been cancelled to know whether I should update it or not. In most cases your code wouldn't even attempt to update the HUD after the hud and the operation has been cancelled but I have a case where my code still tries to update the HUD even though the HUD and the operation has been cancelled (It may sound a bit stupid but its necessary in my case ;) )

[JonasGessner]

OK I added the new commit!

[larsacus]

Let's avoid explicit synthesizers since they aren't necessary anymore.

[JonasGessner]

Ha, I didn't even know that Clang 4.0 has auto synthesis! Cheers for telling me! :P

[JonasGessner]

OK, its pretty solid now. No more bugs and everything works like it should! The progress view can now be fully customized! Let me know what you think

[larsacus]

Can you add me as a collaborator on your branch? With these new changes, I'd like to modify some things to not use assets.

[JonasGessner]

ok, done

[larsacus]

Actually, ignore that - those assets were mine in the sample project. The diff just marked them that you changed them for some reason.

[larsacus]

I couldn't push back to your repository for some reason. I've made some changes in my branch that you can merge in to yours to add to this PR: https://github.com/mutualmobile/MMProgressHUD/tree/JonasGessner-master

[JonasGessner]

Oh, sorry I had removed you as collaborator from my fork :P

[larsacus]

I'm impressed with this. I'll give it another pass tonight or tomorrow and we'll see about getting this in.

I specifically want to pout over the public header diff and make sure that we don't completely break any public api changes for backwards compatibility.

[JonasGessner]

Some of the public APIs have changed, specifically all the ones that contained MMPrrogressHUDProgressStyle

[larsacus]

I just pushed a commit to add back backwards compatibility. Take a look and let me know what you think.

[JonasGessner]

OK its supposed to say "Small improvements" in the commit description :P

[larsacus]

• All the old unit tests are passing
• Public interface maintains backwards compatibility

I think it looks good.

[JonasGessner]

Yeah it seems to be ready now :)

Edit: I'm about to push another small commit, hold on

[JonasGessner]

Is it ok for you that I removed the method? If you want I can also revert it before you merge the pull request

[larsacus]

Yeah removing that method made sense. I think I'll merge this on Monday when I have a computer to give it a full glance over one last time.

[JonasGessner]

OK I added a few more methods and everything seems to work :)

[larsacus]

What was the reason for these last-minute changes? I would prefer that we make as few changes as possible, unless there is a clear benefit to the new structure you have created.

[JonasGessner]

I did these changes because I just replaced MBProgressHUD with MMProgressHUD in one of my projects. I immediately noticed that I needed these changes!

[larsacus]

I will accept 0ddb3ec, but please revert b8e4401, 8c41613 and ea4830f before I will merge this in.

[JonasGessner]

I'd rather not. 8c41613 is basically a revert of ea4830f with some additional fixes. And b8e4401 is more than just useful. MMProgressHUD was using floats for time intervals which is wrong. Time intervals are doubles (NSTimeInterval) and passing floats instead of doubles is never a good idea. That commit moved most defines to a private define file so that by importing MMProgressHUD.h you don't also import loads of unimportant and confusing variables. The +showWithTitle: and especially +dismissAfterDelay: are a must IMO. There is already +showWithStatus: but there isn't +showWithTitle:? Weird.. And +showWithTitle: is useful so its a good addition to the public API calls. There's also several dismiss options with a delay but no +dismissAfterDelay: to simply dismiss the HUD after a time interval, so that method is also pretty much a must. And yeah 8c41613 and ea4830f are a bit weird because I first removed the timer then I brought it back but that was my mistake and I shouldn't have committed the changes right away when I removed the timer. b8e4401, 8c41613 and ea4830f all together work great and I'm using this in my app now without any issues! I hope this clears it up a bit :)

[larsacus]

b8e4401:
I have no problem with converting the floats to NSTimeIntervals (which is correct and I'm not sure how that made it through last time), but I don't agree with the sweeping, massive reorganization of the constants and enums. Why did you move the enums from the MMProgressHUD header? Those are public enums that others are going to need in order to set properties on MMProgressHUD to set it up. The other private constants and macros I'm fine with moving to a private header that isn't publicly imported, but the enums should stay in the MMProgressHUD header.

I'm ok with the "defines" file, but please do not have both a "private" defines and a "public" defines file. If something is meant for public consumption, then it should be in the normal header location. Everything else should be in the "private" header you want and imported on the .m files of other files in which those constants are required. I'm also leaning towards keeping MMHud.h as it was. MMHud can be subclassed, and those constants that you removed from the header should only be needed in MMHud. If it's simply an issue of wrongly importing a class in the .h file instead of a @class forward declaration and an import in the .m file, then that modification would be the preferred first approach before reorganizing the headers.

Why is a public API for a dismiss delay "a must"? The reason it was an internal method was to allow some of the animations to complete and the final state to complete before dismissing the hud. From an implementation stand-point, if you would like to delay the dismiss, then you would simply dispatch_after to the main thread using a delay.

I'm good with adding +showWithTitle: -- you're right -- it should have been there from the beginning since we have +showWithStatus:. However, this commit is both a reorganization and a public header change, so it was difficult to just say "please revert only half of this commit", which wouldn't have made much sense unless I showed you exactly what to revert.

8c41613:
This is not simply a copy/paste revert of ea4830f. Diff these side-by-side and you'll see what I'm talking about.

---

I would really like to accept this pull request even though it's gotten a little out of hand and beyond scope of the original pull request. In the future, please restrict pull requests to their original scope, and open up new pull requests for different features. Also note that just because something is working for you right now doesn't mean it will work for everyone else that is depending on this library in their projects.

[JonasGessner]

Its always a good practice to keep defines separated from your actual classes. Apple does it the same way. However you don't want to have all your defines and variables publicly, thats why I separated the public defines from the private ones.

And of course you can use a dispatch_after call or performSelectorAfterDelay: but that would just make everything harder. If you can do it easier then do it the easy way, thats what I always think.

8c41613:
You're right. I didn't revert the code that I thought was useless. 1. If the hud isn't visible then you also don't need to dismiss it, so that code was unnecessary. 2. And the check if the delay is infinite is also redundant IMO. If the developer messes up and passes an incorrect delay its his fault, there's no need to clean up other people's mess.

[JonasGessner]

And yeah tis pull request just became larger and larger and maybe it shouldn't have grown that much. Part of the problem is also that GitHub automatically adds new commits that I push to my repo, I can't stop that from happening! But I think the changes I made are useful and not in any way redundant.