Swift, tdd

TDD In Practise

When it comes to Testing In Swift, there are 3 keys,

1 – Design your code for clear testability.

Unified Input & Output: In the functional programming world there is this talk about pure function which simply means that same input will always produce the same output no matter where it is called. You don’t have to become Haskell programmers and change all your code according to pure functionality, yet, you may want to inspire by them to make your code easier to test.

Keep Our State Local: In the Apple Community a lot of people are using singleton patters simply because they are used to. We have seen Apple do it like, UIScreen, UIDevice, Bundle, etc. So we as IOS Devs, tend to use it by default even when we really don’t need it. As singletons can be nice for sharing some apis they can also lead you a dangerous paths such as undefined state. So before using it we must think that whether we really need it or not. In summary, my humble suggestion would be try to keep states in local so that we are gonna end up with less bugs and also easier to test the code.

Dependency Injection: When you are testing a state or functionality, all the needs to create output must be declared as you call the testing function, so try not to put variables in the class itself but try to create them while calling the function via putting those variables in initializers. So that, all the needs will always generate the same output with the same input no matter when or where.

2 – Remember that you are going to write a test against all your public api. So keep caution on access modifiers.

Always keep going with framework oriented programming, so that your codes will be easy to test and easy to reuse them.

3 – We all need mocks when it comes to testing, yet be very careful while using them. Remember your only purpose is writing tests to check your real code. Mocks come with a cost and more complexity. And you can end up instead of testing your api, testing too much of your implementation.

Allll credits goes to John Sundell.

Android, kotlin


“Defines whether widgets contained in this layout are baseline-aligned or not.”

By setting android:baselineAligned="false" , app prevents the layout from aligning its children’s baselines, that means app doesn’t worry about where the baseline of other elements in the layout, which increases the UI performance.

Note: By default, baselineAligned is set to true.

Android, proguard


ProGuard — shrinking, optimization, obfuscation, and preverification of Java bytecode.

Proguard optimizes the bytecode, removes unused codes, and obfuscates the classes, fields, methods with shorter names. Optimization operates with java bytecode. Since android runs on Dalvik bytecode which is converted from java bytecode, some optimizations usually doesn’t work well ( So you should be careful ).

The obfuscated code makes your APK difficult to reverse engineer, which is the main reason why most of the developers choose proguard.

Proguard can sometimes break your code up since it renames almost everything. Be sure to thoroughly test your app before release, especially after changing proguard config.

Prevent Obfuscation In Some Classes

Every app has some kind of data classes, models, or some important classes which they cannot be obfuscated. In such circumstances, we cannot let proguard to rename or remove any fields of those classes. It’s a safe bet to add a @Keep annotation on the whole class or methods, or a wildcard rule on proguard-rules.pro.

1 – @Keep Annotation:

Denotes that the annotated element should not be renamed when the code is minified at build time. This is typically used on methods and classes that are accessed only via reflection so a compiler may think that the code is unused.

  public void foo() {

Note that: This annotation is available only when using the Annotations Support Library.

2 – Using ProGuard, keep class fields with wildcard:

-keepclassmembers class com.my.package.** {
    public protected <fields>;
    private *** string*;

Tips & Tricks in Proguard

Android, app, book, currency, designPatterns, developer, doviz, dovizkur, doviztakip, ionic, ios, iphone, iwatch, kur, lifestyle, playstore, software, Swift, swift4, takip, Uncategorized, watch, watchkit, yazilim

Time Tracker IOS Watch Kit App

Hey Everyone!

I have started to create some cool apps(or at least trying to create) for IOS WatchKit recently and noticed that it is way too different than IOS iPhone apps. Here I share Clock – In && Out watch app which records your time and gives you feedback for your time tracker.

repo: https://github.com/rozeridilar/TimeTrackerWatchKitApp

Like your work, love your life || vice versa!

If you have any questions on this pls, do not hesitate to write me back.

Lots of Love, Rozeri.

Android, app, book, currency, designPatterns, doviz, dovizkur, doviztakip, ionic, kur, lifestyle, playstore, Swift, swift4, takip, Uncategorized, yazilim

Swift 4 Skeleton Project

Hey everyone!

Here is skeleton project for our swift projects with mvc, shared folders and some objective C libraries(for UI animations- ProgressHUD etc.)

This project is also base of angela yu’s project!



Alsoo, here is common auto layout issues both programmatically and Main Board Solutions:



book, designPatterns, Uncategorized

Best Book(s) Ever!

Dear All,

If you are interested in not just codding but not repeating your code in any where, I must recoomend ou to read Rob Martin. Uncle Bob, is the man who taught me what OOP really does. Mainly Solid, and not writing the same things n times instead calling the same method or whatever n times, you must read Clean Code. Then, Clean Coder. Tha language is pretty simple for everyone to understand!
you may easily find the book in amazon!