Skip to content

Instantly share code, notes, and snippets.

View donatoaguirre24's full-sized avatar

Donato Aguirre donatoaguirre24

View GitHub Profile
@mykolaharmash
mykolaharmash / ColorSlider.swift
Last active February 7, 2025 17:15
Color Slider Component (SwiftUI)
// A Color Slider that is similar to one in
// iOS 18+ when configuring a tinted Home Screen
// Full video-walktrough on building this component: https://youtu.be/VFVyN5hNW24
import SwiftUI
fileprivate let SLIDER_HEIGHT = 34.0
fileprivate let KNOB_DIAMETER = SLIDER_HEIGHT + 4.0
struct ColorSlider: View {
@juanchoperezj
juanchoperezj / AppDelegate.mm
Last active April 19, 2025 05:22
Use RocketSim Network Monitoring with both React Native CLI generated and Expo projects
// imports...
@interface RocketSimLoader : NSObject
- (void)loadRocketSimConnect;
@end
@implementation RocketSimLoader
@pesterhazy
pesterhazy / building-sync-systems.md
Last active April 16, 2025 11:29
Building an offline realtime sync engine

So you want to write a sync system for a web app with offline and realtime support? Good luck. You might find the following resources useful.

Overview articles

Everything I Know About UI Routing

Definitions

  1. Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
    1. pathname - The "file/directory" portion of the URL, like invoices/123
    2. search - The stuff after ? in a URL like /assignments?showGrades=1.
    3. query - A parsed version of search, usually an object but not a standard browser feature.
    4. hash - The # portion of the URL. This is not available to servers in request.url so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things.
    5. state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.

Note

Apple will reject apps that are using private url schemes (Ugh, Apple....) if they are pretty much obvius. Some apps are rejected and others are not, so, be aware of this issue before implementing any of those URL's in your app as a feature.

Updates

  • [UPDATE 4] iOS 10 update: apparently settings now can be reached using App-Pref instead of prefs
  • [UPDATE 3] For now you just can use url schemes to open your apps's settings with Swift 3.0 (Xcode 8). I'll keep you informed when OS preferences can be reached
  • [UPDATE 2] The openURL() method of UIApplication is now deprecated. You should use application(_:open:options:) instead
  • [UPDATE 1] Not yet tested in iOS 10. It will fail because of policies changes in URL scheme handling.
@robertpainsi
robertpainsi / commit-message-guidelines.md
Last active April 5, 2025 15:33
Commit message guidelines

Commit Message Guidelines

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
@jemshit
jemshit / proguard-rules.pro
Last active February 18, 2025 12:50
Proguard Rules for Android libraries
# If your project uses WebView with JS, uncomment the following
# and specify the fully qualified class name to the JavaScript interface
# class:
-keepclassmembers class fqcn.of.javascript.interface.for.webview {
public *;
}
### RxJava, RxAndroid (https://gist.github.com/kosiara/487868792fbd3214f9c9)
-keep class rx.schedulers.Schedulers {
public static <methods>;
@wojteklu
wojteklu / clean_code.md
Last active April 18, 2025 12:16
Summary of 'Clean code' by Robert C. Martin

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.


General rules

  1. Follow standard conventions.
  2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
  3. Boy scout rule. Leave the campground cleaner than you found it.
  4. Always find root cause. Always look for the root cause of a problem.

Design rules