Fixing Mac OS X Bluetooth Disconnect Issues

I use a late-2015 iMac (currently) running OS X High Sierra as my main work machine. From day 1 till just a few days ago, bluetooth has worked flawlessly on this machine. The bluetooth Apple keyboard and TrackPad 2 that came with the iMac both paired seamlessly right out of the box, and I’ve never had a connection drop or any other issue, even after going through 2 rounds of major OS upgrades (first to Sierra, and now to High Sierra).

Then suddenly out of the blue a few days ago, the bluetooth connections to both the keyboard and trackpad would drop roughly 20-30 seconds after the machine wakes from sleep. Most times, they would not reconnect on their own, and sometimes, the bluetooth status of the machine would actually report bluetooth was OFF with no option to turn it back ON.

Simply removing the devices and re-connecting them would work to keep them connected only until such time that I sleep the machine and wake it up again. Whereupon the whole disconnect cycle would repeat.

Trashing the Bluetooth prefs file and resetting the machine SMC did not solve this problem. Finally what seems to have done the trick to fix it is Resetting the Bluetooth Module on the iMac via a little known special menu accessible via holding “Shift + Option” then clicking on the bluetooth icon in the top menu bar.

This brings up the among other things a “Debug” sub-menu with the option to “Reset the Bluetooth Module”. And easy as that, disconnect issues have now been resolved!

Advertisements

Fixing dispatch_async error in Swift 3/4

If you are copying some older Swift code (say circa 2014/15 or older) off the web to ensure some code is executed on the main queue, such as like this:

dispatch_async(dispatch_get_main_queue(), {
//do something that must be done on the main queue
})

You will be greeted with these 2 errors by Xcode:

‘dispatch_async’ has been replaced by instance method ‘DispatchQueue.async(execute:)’
‘dispatch_get_main_queue()’ has been replaced by property ‘DispatchQueue.main’

And unfortunately Xcode doesn’t offer to “fix” this for you automatically as it often does with other method calls that have been deprecated.

The new way to perform such a call is simply this:

DispatchQueue.main.async {
//do something that must be done on the main queue
}

 

PHP usort is slow slow ssslow…..

PHP’s native usort array sorting function is handy especially when you need to sort an array by some custom criteria, and other sorting options like sort, asort or ksort just don’t have enough flexibility.

But man, on any reasonably sized dataset, usort is just too slow! How slow you ask? E.g. with an array of 150 elements, using usort adds 3 seconds to loading time on a webpage that displays this data (versus no sorting at all). 3 seconds might not seem like much, but consider:

  • Most nowadays web users are accustomed to pages loading in 1-3 seconds total, otherwise they simply click back and don’t bother waiting. So using up 3 seconds just for a sorting function is not really acceptable
  • That 3 second lag for usort to do its thing gets exponentially larger as the dataset grows

Is there a solution? Only thing I can think of is code refactor to not require usort. Sorry but that’s the sad truth.

Easy UIPickerView with RxSwift & RxCocoa Magic

RxSwift (and RxCocoa) make it super easy to wire up a UIPickerView for your IOS project. No need to bother with the UIPickerViewDataSource and Delegate protocols and the attendant methods that you would normally be required to implement. Instead, it can be as simple as this in your viewcontroller:

import UIKit
import RxSwift
import RxCocoa

class MyViewController: UIViewController {

  // MARK: – Variables
let
disposeBag = DisposeBag()
var pickerView = UIPickerView()

  override func viewDidLoad() {
    super.viewDidLoad()
    setupRx()
}

func setupRx() {

        //#1 bind your data to pickerview
Observable.just([“Item 1″,”Item 2”, “etc”])
                             .bind(to: pickerView.rx.itemTitles) { _, item in
                return \(item)”
         }.disposed(by: disposeBag)

        //#2 handle pickerview selection
pickerView.rx.itemSelected.asObservable().subscribe(onNext: {item in

            //item.row gives you the index of the selected item, so do what you need with                  it

            //also here you can call .resignFirstResponder() on whatever element brought up the pickerview (e.g. a button) in order to close the pickerview

        }).disposed(by: disposeBag)

        //optional: preselect the second item in pickerview
pickerView.selectRow(1, inComponent: 0, animated: true)

}

} //end class

So what’s going on?

In #1, we bind our data to the pickerview. In the example we simply have a small array of some strings to display. This could instead come from coredata, over the network, or whatever your app requires.

In #2, we set up the subscription to observe selections made on the pickerview. In the closure’s body you can put whatever business logic you need to handle the selection, with “item.row” giving you the index of the selected item from the array. You would also call resignFirstResponder() here in most cases in order to close the pickView.

And that’s it! Neat huh?

 

Creating Unwind Segues in Swift 3 and 4

Unlike (normal forward) segues, I find the process of setting up unwind segues in an IOS Swift project not that intuitive. Hence, whenever I haven’t used one in a while, I need a little reminder on how to get it hooked up.

There’s a nice little write up by developer Luna An here that sums it all up very neatly.